ws@tools.de (Wolfgang Solfrank) writes:
> > : Is /dev/ksyms the best place for this?  Why not /kern/ksyns?
> > 
> > Probably so that you can get at ksyms without having to have kernfs.  :)
> 
> I knew that someone was going to say this.  But can anyone tell me what's
> so bad about kernfs?  Especially if we are now going to bloat the kernel
> with a linker anyway...

Well, for one, at least in the near future /dev exists by default,
because it's on the root file system, and because 'device nodes work.'
/kern or similar things have to be mounted by hand.  Yes, you could go
some ways to fixing that, but if you're going to start having random
file systems mounted automatically by the kernel or init, where do you
stop?


> (You might tell from the above that I'm more than unhappy with this trend
> to become yet another Slowlaris, where you've got a 500k kernel that cannot
> even read a single byte from any device.  And while being here, what's good
> about having the linker in the kernel?  Looks like I must be missing
> something...)

from my perspective, the biggest long-term advantage of having the
linker in the kernel is the ability to provide a way to have immutable
(and perhaps even cryptographically signed/secure) loadable modules.

with the loader in user-land, the kernel is basically at the mercy of
the user-land loader.  if it screws up or is subverted, then you lose.
basing the stability and security of the system on a user-land
interface which is probably easily undermined is ... a bad thing, from
my perspective.  if you're letting a 'random' user program (which,
granted, must be run as root) load 'random' data into your kernel,
you're losing.  you want to be able to trust all parts of the loading
process.  Getting rid of a potential source of insecurity (the way
data is moved into the kernel) helps that.  (In a fully-functional
world, modules wouldn't only be loadable at low security levels, etc.)

with the loader in the kernel, you could also try to use various other
technologies to make kernel modules safer.



cgd
-- 
Chris Demetriou - cgd@netbsd.org - http://www.netbsd.org/People/Pages/cgd.html
Disclaimer: Not speaking for NetBSD, just expressing my own opinion.