Hi,

since I don't want this to get into YAFW, this will be my last message to
this subject for a while 8-O.

> : The first one can surely be addressed by having the linker in /, no need
> : to have it in the kernel, or what?
> 
> Not necessarily.  If your / doesn't contain the currently-booted kernel
> file, or at least /netbsd doesn't correspond to it, and you need LKMs in
> order to mount /usr ....

Hmm, this sentence again doesn't make too much sense to me.  The "and" seems
to imply that you might get at the kernel if /usr is mounted (did you mean
really that?), otherwise the reference to /usr doesn't make sense at all
(see, I proposed to put the (LKM-)linker into /).  And the former is
nicely taken care of by /dev/ksyms (or, as I would prefer, /kern/ksyms).

> : The second one looks even more bogus to me.  What gain would "shared objects"
> : in the kernel be?  Shared objects are meant to be just that, _shared_.
> : What would the kernel share these objects with?
> 
> That's why it is in quotes.  Position independent code allows for easier
> linking into the kernel; you only "link" it once, and just "relocate" it
> when loading the kernel.  They aren't "shared" objects per se.

But, as Chris already posted, pic code is quite a bit larger/slower on
some platforms.  Do you really want to pay that price during all the use
of a module for the gain of one linkage pass?

Ciao,
Wolfgang
-- 
ws@TooLs.DE     (Wolfgang Solfrank, TooLs GmbH) 	+49-228-985800