Jason Thorpe <thorpej@nas.nasa.gov> writes:
> 	- mount calls internal LKM code to search for "vfs/cd9660.so".

It's not clear to me that it's appropriate to have the loadable
modules be .so's (implying to me PIC) rather than .o's (not PIC).

The savings of PIC objects don't buy you much: you're only going to be
using one copy at a time, you're not going to be paging 'text' bits of
them back to the original file, etc.  On the other hand, on most
architectures, PIC code has at least some additional execution time
and/or code size when compared to non-PIC code.


>  > - Bdevsw/cdevsw is gone, instead there is a devsw handler to which
>    device modules are registered/unregistered.
> 
> ..okay.  There needs to be a way for userland to query LKMs about e.g.
> which system call number they got, which c/b major they got, etc.  Some
> sort of generic "dynamic attributes" query mechanism.

The Solaris tools aren't great in all ways, but they may be a decent
example and starting point.




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