Re: DEVFS_FS

[Jamie Lokier <jamie@shareable.org>]

Bryan Henderson wrote:
> To me, the criticism of devfs missed its most important feature:  It was 
> fundamentally designed to eradicate device numbers altogether.  Device 
> numbers are an ancient technology.  In today's world, a device's basic 
> name should be something like /dev/sound/mixer instead of a small number.

I agree.

Numberless devices are so useful that even some non-devfs systems have
a few drivers which allocate a number and require userspace to do
horrible things like parse /proc/devices to open the device.

Versions of udev that use /lib/udev-state/devices.tar.bz2 to
workaround the limitation described below completely break this
numberless feature.

> If you miss that, and think devfs is about making mnemonic aliases for 
> small numbers, then it's easy to see devfs as a poor approximation of 
> udev.

In my experience, udev has not been as good as people say, because
while devfs just works, the udev-based system I'm using right now
requires all manner of manual modprobing before basic things like
pppd, openvpn and mtools work.

> >Only devfs (or the lookup trapping facility used in my remake
> >of it) can configure new devices on demand based on accesses to files
> >missing from /dev, which allows for faster boot time (no need
> >to initialize device you won't use during this session), easier fixing
> >of device driver bugs, and potentially less memory utilization
> 
> Why is that?  First, let me make sure I parsed the sentence right:  You're 
> saying the only way to configure devices on demand such that you get all 
> those benefits is by using your lookup trapping facility in conjunction 
> with your version of devfs?

Wrongly parsed.
He's saying _either_ devfs _or_ looking trapping is sufficient.

> Also, I'm not clear on what memory utilization or device initialization 
> delays we're talking about.

Examples: If you compile all USB drivers into the kernel, or if you
modprobe them during boot scripts, then boot time is extended by the
time taken to initialise the host controllers and connected devices.
If you compile in SCSI drivers, boot time is further extended by the
time taken to probe and initialise your SCSI devices.

The time for initialising devices which you don't want to use this
session can be quite significant, if you find a few seconds to be
significant.

Same goes for unnecessary memory utilisation.  Having drivers loaded
for devices which you aren't using can be significant, if you find a
few hundred kbytes significant.

-- Jamie