The /dev directory has existed in Unix systems for a long time, which
doesn't mean that it should be changed for just that reason. Most of
us that have used Unix-like systems are familiar with what it represents
and how to use it.
Here are some reasons why people have wanted a "dev-fs" system.
1. Number of entries. I've just looked at my system and I have well over
650 entries and I have nothing special on system.
2. Many unused entries. A standard setup will create many entries, even
though you don't need them. Having unused entries affects the lookup of
/dev.
3. When accessed, the atime on the /dev file will be updated. This means
that when null, zero etc. is used, an update of the atime is required,
this may not cause a significant impact, however, the atime on the /dev
file does not provide any useful information. There is currently a
patch around can prevent these updates, however these are primarily to
help programs like news servers, and IMHO are only a workaround for
resolving the /dev issue.
4. One of the items mentioned in the FSSTND stated the idea of having a
read-only root FS. The idea was to reduce the problem of root FS corruption
and not being able to recover from it without re-installation (MS method
of recovery). Having a read-only FS affects the ability to change
attributes such as ownership of tty files.
5. Maintenance of the /dev doesn't occur frequently, but when it does then
it's up to the system administrator to resolve the synchronisation between
major/minor numbers the kernel has the drivers at and what has been stored
on the filesystem.
I've done some initial fiddling around with the sources (nothing major
though), and read messages from various people commenting on the subject,
and come up with the following points.
- Similiarities with proc fs.
- Kernel bloating.
- Handling of loadable modules.
- Compatibility with existing Unix-like systems.
- Similiarities with proc fs.
The majority (if not all) of Linux users use the proc filesytem, as it
provides a lot of useful system information in a easily readable fashion.
As such, hooks into functions based on existing lookup tables can be created
off a procfs entry.
- Kernel bloating.
This is the only reason I've seen against the idea of the devfs, and this is
certainly an issue to be concerned with. Although I've used the term devfs,
It doesn't mean a completely different FS to procfs but more likely a integral
part of it.
- Handling of loadable modules.
Currently when an access to a /dev file occurs, and the driver associated with
the major/minor numbers doesn't exist, the kernel asks kerneld to load it.
This scheme won't work with missing dev entries. If we create a specific
proc_lookup wrapper (like in root.c) for the dev directory and cater for the
case ENOENT to request_module. All that needs to be done would be an interface
to enable modules (and compiled in drivers) to register themselves with the
kernel with names to be placed in dev, eg floppy.o could register fd0, fd0...
An advantage with this is that you would only have dev entries for devices
you currently have loaded.
- Compatibilties with existing Unix-like systems.
It wouldn't be impossible to implement a /proc/dev to allow the above
mechanism, but most Unix-people assume things like /dev/null. This could
be addressed in two ways.
ln -s /proc/dev /dev
or a more complicated solution would be to have the procfs mounted / initially
(with /dev /system /proc hanging off it) and then perform some kind of
transparent mount the rootfs (without a /dev /proc .. ) on top of /. therfore
providing /sbin /etc /dev /proc /system whatever.
IMHO I like the second solution, however I'm not sure how the mount stuff works
yet! so opinions please.
all flames to /dev/null (or is that /proc/dev/null) anyway
c ya
karl
(karl@ronin.u-net.com)