So, what would an extra "filesystem" do that a slightly-souped-up
MAKEDEVS (and kernel patches which add drivers patching MAKEDEVS as well
and letting you know to re-run it) wouldn't do, and can you make it
small without taking away any of the features I want/need to keep? I'm
guessing the answers are "not much" and "no"...
> - Handling of loadable modules.
> Currently when an access to a /dev file occurs, and the driver associated with
> the major/minor numbers doesn't exist, the kernel asks kerneld to load it.
> This scheme won't work with missing dev entries. If we create a specific
> proc_lookup wrapper (like in root.c) for the dev directory and cater for the
> case ENOENT to request_module. All that needs to be done would be an interface
> to enable modules (and compiled in drivers) to register themselves with the
> kernel with names to be placed in dev, eg floppy.o could register fd0, fd0...
>
> An advantage with this is that you would only have dev entries for devices
> you currently have loaded.
I want /dev entries for devices which aren't loaded, but can be loaded.
Doing that with some "devfs" would entail extra functions in all modules
and some really bizzarre extention to depmod at bootup, to not only
rebuild module dependencies, but load the modules far enough to tell the
kernel what device files they provide...
Keith
-- "It moved faster. I swear, they are evolving right before my eyes. If you see something this big, with eight legs coming your way, let me know; I have to kill it before it develops language skills." --- Ambassador Londo Mollari, in 'Sic Transit Vir' (Babylon 5)