Re: DEVFS_FS

[Jamie Lokier <jamie@shareable.org>]

Mike Waychison wrote:
> The udev model does this very
> effectively: where there is hardware backing the device files, there is
> no good reason to not load the drivers and have policy set once and for
> all on udevstart.

(a) boot time, (b) it's typically a few hundred k to be saved.

> The only need for trapping that I can see is for modules that don't have
> hardware backing them, such as tun and loop.

There's quite a few devices like that.

> In fact, the opposite is true: userspace should not care at all about
> major/minor.  Userspace should care about the semantics of the available
> device nodes available in /dev.  With hardware, I want to _see_ the
> device nodes created when I _add_ hardware.  udev handles this semantic
> very well.  Where it fails is solely in the added devfs semantic of
> modprobing on lookups of non-existing device nodes.  _This_ is the case
> where some form of trapping would help very much.

I agree, this is desirable behaviour.  But it isn't perfect.

Better than trapping would be if /dev/net/tun0 and so forth did
actually exist in /dev, to indicate the availability of those devices,
but the modules were still autoloaded on first access.

It would also be nicer if the device nodes were created to indicate
available/installed devices, without actually initialising the devices
or loading the bulk of their driver until they're needed.

In other words, if /dev were auto-generated based on all available
hardware and all available non-hardware drivers for the current
kernel, including modules not yet loaded.

That would be better IMNSHO, to the extent that it's possible.

Although it's necessary to load drivers for some devices (like ISA
cards) to detect them, it isn't necessary to load PCI drivers to
detect that they are present.  A mapping directly from detected PCI
ids to whatever udev needs could be extracted from the drivers at
compile time.  Such mappings nearly exist now, except that the mapping
is from ids to drivers, instead of ids to dev info.

-- Jamie