Re: updating COMPAT_LINUX for linux 2.6.x support (take 2)

2010-06-16 Thread Chuck Silvers
On Mon, Jun 14, 2010 at 03:25:56PM +, Andrew Doran wrote: > On Sun, Jun 13, 2010 at 10:59:45PM -0700, Chuck Silvers wrote: > > hi folks, > > > > ok, more progress. linux32 is working now and I fixed a few other bugs > > along the way. > > > > the updated diff is in > > ftp://ftp.netbsd.org/p

Re: Enabling built-in modules earlier in init

2010-06-16 Thread Paul Goyette
On Wed, 16 Jun 2010, Antti Kantee wrote: On Wed Jun 16 2010 at 06:31:59 -0700, Paul Goyette wrote: The attached diffs add a new mod_disabled member to the module_t structure, and set the value to false in each place that a new entry is created. (Since all of the allocations of module_t structu

Re: updating COMPAT_LINUX for linux 2.6.x support (take 2)

2010-06-16 Thread Mindaugas Rasiukevicius
Andrew Doran wrote: > - The dup code for fork1() code makes me uncomfortable. Maybe it's > worthwhile changing our native code so that LIDs are always allocated > from the PID table or something along those lines? Tend to think these > should be globally unique with the system and not just

Re: Removal of recursive vnode locks

2010-06-16 Thread Mindaugas Rasiukevicius
Juergen Hannken-Illjes wrote: > > I propose to completely remove the concept of recursive vnode locks by > eliminating vn_setrecurse(), vn_restorerecurse() and LK_CANRECURSE. > Definitely, and they should never come back. - lockcnt = lvp->v_lock.vl_recursecnt + - rw_write_held(

Re: Enabling built-in modules earlier in init

2010-06-16 Thread Antti Kantee
On Wed Jun 16 2010 at 06:31:59 -0700, Paul Goyette wrote: > The attached diffs add a new mod_disabled member to the module_t > structure, and set the value to false in each place that a new entry is > created. (Since all of the allocations of module_t structures are done > with kmem_zalloc() I

Re: Enabling built-in modules earlier in init

2010-06-16 Thread Paul Goyette
On Wed, 16 Jun 2010, Antti Kantee wrote: I have to admit I haven't been following your work too closely, but builtin modules are initialized either when all of them are initialized per class or when their initialization is explicitly requested. So if whatever uses PCIVERBOSE requests the load o

Re: l_private (Re: updating COMPAT_LINUX for linux 2.6.x support (take 2))

2010-06-16 Thread Andrew Doran
On Wed, Jun 16, 2010 at 10:27:16AM +0200, Joerg Sonnenberger wrote: > On Wed, Jun 16, 2010 at 06:30:23AM +, YAMAMOTO Takashi wrote: > > i think ucontext is more flexible because this way the kernel doesn't > > need to know which register etc is used for tls. The amount of code in kernel to sup

Re: Removal of recursive vnode locks

2010-06-16 Thread Andrew Doran
On Wed, Jun 16, 2010 at 09:57:49AM +0200, Juergen Hannken-Illjes wrote: > With mount_domount() the last consumer of recursive vnode locks has left. > > I propose to completely remove the concept of recursive vnode locks by > eliminating vn_setrecurse(), vn_restorerecurse() and LK_CANRECURSE. > >

Re: Enabling built-in modules earlier in init

2010-06-16 Thread Andrew Doran
On Wed, Jun 16, 2010 at 09:47:54AM +0300, Antti Kantee wrote: > On Wed Jun 16 2010 at 12:13:38 +1000, matthew green wrote: > > i think having a class of builtin modules that are available during > > autoconfig isn't a bad thing. perhaps the right answer is infact to > > convert MODULE_CLASS_SECMOD

Re: Enabling built-in modules earlier in init

2010-06-16 Thread Antti Kantee
On Wed Jun 16 2010 at 04:58:37 -0700, Paul Goyette wrote: > Yeah, my initial pass at the xxxVERBOSE modules used module_load() with > MODCTL_LOAD_FORCE flag. And it worked just fine for both built-in and > boot-loaded modules. Then, at John Nemeth's request, I modified it all > to use module_a

Re: Enabling built-in modules earlier in init

2010-06-16 Thread Paul Goyette
On Wed, 16 Jun 2010, Antti Kantee wrote: I have to admit I haven't been following your work too closely, but builtin modules are initialized either when all of them are initialized per class or when their initialization is explicitly requested. So if whatever uses PCIVERBOSE requests the load o

Re: Enabling built-in modules earlier in init

2010-06-16 Thread Antti Kantee
On Tue Jun 15 2010 at 17:10:55 -0700, Paul Goyette wrote: > Currently, built-in kernel modules are not enabled until very late in > the system initialization process, right after we create process #1 for > init(8). (As an exception to this, secmodel modules are enabled much > earlier.) > > Unf

Re: Enabling built-in modules earlier in init

2010-06-16 Thread Paul Goyette
On Wed, 16 Jun 2010, Antti Kantee wrote: On Wed Jun 16 2010 at 04:13:54 -0700, Paul Goyette wrote: With the current ways of secmodel register, I'd be damn careful to not push it around. The effect is that if it's called 0 times, you have a system which allows everything. So if your suggestion

Re: Enabling built-in modules earlier in init

2010-06-16 Thread Antti Kantee
On Wed Jun 16 2010 at 04:13:54 -0700, Paul Goyette wrote: > >With the current ways of secmodel register, I'd be damn careful to not > >push it around. The effect is that if it's called 0 times, you have a > >system which allows everything. So if your suggestion is implemented > >and you're testin

Re: Enabling built-in modules earlier in init

2010-06-16 Thread Paul Goyette
On Wed, 16 Jun 2010, Antti Kantee wrote: On Wed Jun 16 2010 at 12:13:38 +1000, matthew green wrote: i think having a class of builtin modules that are available during autoconfig isn't a bad thing. perhaps the right answer is infact to convert MODULE_CLASS_SECMODEL into say MODULE_CLASS_EARLY,

Re: mbuf pool allocator can sleep in interrupt context?

2010-06-16 Thread Darren Reed
Thor Simon wrote: We have a very busy system (it is a load test target) which continually has several thousand TCP connections open and often has bursts of thousands of nearly simultaneous connection requests. It's running a netbsd-5 branch i386 kernel. We have been seeing LOCKDEBUG panics. Th

Re: l_private (Re: updating COMPAT_LINUX for linux 2.6.x support (take 2))

2010-06-16 Thread Joerg Sonnenberger
On Wed, Jun 16, 2010 at 06:30:23AM +, YAMAMOTO Takashi wrote: > i think ucontext is more flexible because this way the kernel doesn't > need to know which register etc is used for tls. In many cases, the kernel has to know about the private mapping because it has to update it on context switch

Removal of recursive vnode locks

2010-06-16 Thread Juergen Hannken-Illjes
With mount_domount() the last consumer of recursive vnode locks has left. I propose to completely remove the concept of recursive vnode locks by eliminating vn_setrecurse(), vn_restorerecurse() and LK_CANRECURSE. A diff is attached. Comments or objections anyone? -- Juergen Hannken-Illjes - ha