DragonFly kernel List (threaded) for 2004-04
Re: devfs vs udev/hotplug
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
X-Trace: 1082698772 crater_reader.dragonflybsd.org 50175 188.8.131.52
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:4749
Diego Calleja García escribio:
> and unlike with devfs, nobody will notice that someone is trying to access a
> device node which doesn't exists and load a module in consequence.
> restore that devfs behaviour...the lack of this has been (and is) the
> biggest problem against udev adoption (and the inspiration of everal
> "udev vs devfs" flamewars :)
When I first skimmed your post, what you were suggesting didn't click.
Now I understand why.
Supposedly this loading/unloading feature is desirable because it would
allow embedded developers to keep as many device modules out of the
kernel as possible in order to save "a few kb"? I can't think of any
other excuse for why someone would need, or even want, this feature
other than the one you have stated.
Maybe I'm wrong but, I think embedded systems tend to have a small
number of devices ( and a small number of device types ) attached to
them so the developers would not be dealing with that many modules to
begin with. This is probably even more likely in the case that you are
suggesting where there is a need to "save a few kb".
Then you are suggesting that DF add a whole new pseudo-filesystem, plus
a udev daemon, plus code for this rare special circumstance for embedded
developers. Why? So DF can let these embedded systems dynamically load
and unload modules in order to "save a few kb of mem".
People in favor of this loading/unloading feature want to add hundreds
of kilobytes of code to the system in order to save a few kilobytes at
That argument doesn't sum properly.