Re: devfs vs udev/hotplug

[Diane Bruce <db@xxxxxx>]

On Fri, Apr 23, 2004 at 01:39:32AM -0400, esmith wrote:
> Diego Calleja Garc?a escribio:
> 
> >and unlike with devfs, nobody will notice that someone is trying to access 
. ..
> 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.

  uh no. With an embedded board, devices are pretty much known a priori.
There is really no need to probe (fold bend and mutilate) devices, since
you "know" what address they are at, what they are and what IRQ they are at.
This is changing (as the embedded world gets a little murkier) with
the addition of a PCI or some other bus. Still, in those cases you are
going to "know" a priori what devices you are going to support. Quite often
you'll have an emedded board that you want to hang an IDE off of, or
perhaps an extra ethernet card. But you know the problem set ahead of 
time, its not the same thing as a general purpose workstation where
just about anything can show up on the bus and has to be probed and
a driver found for it.

  So, as Matt says, you could just compile the darn drivers into the kernel
and be done with it. But what if you wanted to generate a binary only
release? i.e. build a one kernel ROM that you could use on all your
product line and just switch the ROM that holds your driver set?

> 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".

  Correct. In general. But read above. You still would want to keep things
separated. One ROM to rule them one ROM to drive them and one ROM .. oh wait...

  I am rather a fan of the concept of moving device probes outside
of the kernel, because of the embedded world. Build up a device list
as it boots, present to kernel. Embedded system could have the drivers
compiled into the kernel, "know" the devices they can deal with, then
load modules right from either a local ROM or a filesystem.
Since one _knows_ where things are, there is no need for a cmpilicated
probe routine. its hard coded in. Oh you might have situations where
you'd want to do some sanity tests, but in general this is fine.
Of course, this immediately breaks when you have removable devices such as USB
firewire etc..

  Some of the OS/9 concepts were cool for that. modules were coompiled
with a header and a checksum. kernel as it booted would scan ROM looking
for the module headers, check the checksum and then add.


- Diane