devfs vs udev/hotplug

[esmith]

0422223846.20fdf4ef.diegocg at xxxxxxxxxxx>
In-Reply-To: <20040422223846.20fdf4ef.diegocg at xxxxxxxxxxx>
Content-Type: text/plain; charset=ISO-8859-15; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 42
Message-ID: <4088ac14$0$50175$415eb37d at xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
NNTP-Posting-Host: 24.225.200.74
X-Trace: 1082698772 crater_reader.dragonflybsd.org 50175 24.225.200.74
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 
run time?

That argument doesn't sum properly.