Date: Fri, 21 Dec 2012 14:49:13 -0700 From: Jim Harris <jim.harris@gmail.com> To: John Baldwin <jhb@freebsd.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r244549 - head/sys/dev/nvme Message-ID: <CAJP=Hc9PvmR5yUMH5=YvQ9e%2BtJ7j3PqtDHGebA8nvvTqB%2BX=xw@mail.gmail.com> In-Reply-To: <201212211424.16934.jhb@freebsd.org> References: <201212211913.qBLJDmpm019837@svn.freebsd.org> <201212211424.16934.jhb@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Fri, Dec 21, 2012 at 12:24 PM, John Baldwin <jhb@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. Another benefit of using kproc here though would be to make it more consistent with pre-8.0 behavior (before kthread_create was renamed to kproc_create).
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAJP=Hc9PvmR5yUMH5=YvQ9e%2BtJ7j3PqtDHGebA8nvvTqB%2BX=xw>