svn commit: r244549 - head/sys/dev/nvme

[John Baldwin]

On Friday, December 21, 2012 04:49:13 PM Jim Harris wrote:
> On Fri, Dec 21, 2012 at 12:24 PM, John Baldwin <jhb at freebsd.org> wrote:
> > On Friday, December 21, 2012 2:13:48 pm Jim Harris wrote:
> > > Author: jimharris
> > > Date: Fri Dec 21 19:13:48 2012
> > > New Revision: 244549
> > > URL: http://svnweb.freebsd.org/changeset/base/244549
> > > 
> > > Log:
> > >   Put kthreads under curproc so they are attached to nvmecontrol rather
> > >   than pid 0.
> > >   
> > >   Sponsored by:       Intel
> > 
> > Hmm, is this really wise?  I'm not sure how well the kernel would handle
> > a kthread belonging to a userland process.  You could just have each
> > test create a new kproc that holds the associated threads for that test
> > instead perhaps?
> 
> Just so I'm aware, what sorts of problems might you expect if a kthread
> belongs to a userland process?  I'm not opposed to changing this as you
> suggest, but would like to know for my own understanding since I haven't
> observed any problems with it on my system.

I'm not sure what might break. :(  I just know that I have always expected
a kthread to belong to a kernel process, and it wouldn't surprise me if
there wasn't some code somewhere that assumed TDP_KTHREAD implied that the
associated process as a kernel process (P_SYSTEM).  Perhaps it would work,
but I don't think many folks have considered that edge case or coded for it.

OTOH, it might be an interesting way to implement aio (though I think aio
should be implemented directly in userland using user threads, though
possibly not pthreads so a single-threaded application doesn't pay a
penalty).

-- 
John Baldwin