Subject: Re: /dev/ksyms
To: None <email@example.com>
From: Wolfgang Solfrank <firstname.lastname@example.org>
Date: 01/25/1999 16:56:39
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?
ws@TooLs.DE (Wolfgang Solfrank, TooLs GmbH) +49-228-985800