On Wed, 12 Apr 2000, Horst von Brand wrote:
>> If you wanted to be a purist, modules need a new function for reporting
>> devfs information... init_module, delete_module(?), devfs_module? That
>> certainly fixes one problem (and kills the need for devfsd.)
>
>No. How do you load a module for /dev/foo117, when /dev/foo117 doesn't
>currently exist? The kernel shouldn't have to know about each and every
If it doesn't exist, nothing gets loaded. THAT'S THE WHOLE PROBLEM!
The existing kerneld/kmod method will only request something be loaded
when the node is referenced -- i.e. /dev/foo117 has to exist in the file
system. "devfsd" is nothing more than a reborn kerneld -- the most
reinvented wheel in history?
My suggestion is merely one of many ways to present the devfs information
available for this module to the devfs internals without loading the module.
Basically, devfs needs to know what to load when someone asks for /dev/foo117
when foo117 doesn't exist yet. In fact, devfs could present the file foo117
in it's virtual file system before the driver is loaded, but that's open
for debate. And unpredictable hot-plugable devices skews the playing
field.
>userland involvement, with some configuration file that tells the daemon
I'd try to avoid manually mucked with configuration files or software
that has to be updated every tuesday... if there is a well defined method
of finding this information, then it should be used. The config file is
a "last resort" to handle odd things or the wishes of the administrator
(for example, _I_ turn off the ipx and appletalk modules.)
Config files are no better than the existing methods of /dev and kmod.
Someone still has to manually add dev entries and edit conf.modules over
time. devfsd does nothing to address this.
>what to do in each case. This is elegantly solved in the traditional case
>with just a device file created before use, major/minor (more generally,
>device id) tell the kernel what module to ask for. You can then also
>painlessly set (and preserve) permissions on the device in the filessytem.
>Cost is one inode on disk per device.
True. However, there is alot of pressure to move away from the static
major/minor numbering infavor of a dynamic namespace. This is a perfectly
valid and desirable goal, however devfs is a bad attempt at doing this.
(No offense intended.) The entire problem boils down to a form of database
optimization -- the device namespace is a database... some name has to
map to a kernel function to deal with open(), read(), etc. [the existing
non-devfs system has _alot_ of indirection in there.]
Any linkage between a persistant, on disk structure and transient, in
kernel space data will be difficult to pull off. One way would be some
sort of symlink-ish hack -- there's no longer a static mapping between user
and kernel (major/minor numbers.) The more I think about it, the uglier it
gets. (I can paint a lovely theory... converting white board to C will
be a problem.)
>The whole devfs idea more and more looks like ballast to me.
no comment.
--Ricky
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sat Apr 15 2000 - 21:00:21 EST