> 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.
I have 1357, occupying a total disk space of--hold onto your seat--47 blocks.
> 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.
Linux is awfully good at caching. I think it can cope with 47 blocks, but
if it becomes a problem, the rm utility can undo whatever mknod hath done.
> 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.
Oh no, somebody hacked into my system last night and wiped wtmp among
other things! Hmm, what about Mr. Heyes' suggestion? Was this intruder
hip to that?
#ls -lu /dev/tty*|less
Hmm, looks like tty3, but not ttyp0, got used last night...an inside job!
> 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.
That would be really nice. I presume you're also in favor of /proc/mtab
(yay!). Until that happens, I keep only 9 to 16 MB of stuff in /,
depending on how many kernel versions inhabit /boot/ and /lib/modules/.
That's down to a size that can be easily tarred up, stashed on another
partition or something, and untarred after booting from floppy--not the
most elegant thing, but workable.
> 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.
>From your second point about the "standard setup" it sounded like you
were talking about distributions. Surely a good distribution has
something like a dev.tgz, dev.rpm or dev.deb which can be installed from
floppy, wiping out obsolete entries in /dev/? The device
numbers don't get changed too frequently though, fortunately for those of
us who like to make weird links in /dev. Speaking of which, how would
/proc/dev/ account for me wanting to have /proc/dev/mouse, /proc/dev/modem,
/proc/dev/printer and /proc/dev/tape linked to /proc/dev/cua0,
/proc/dev/cua1, /proc/dev/lp1 and /proc/dev/nst0? Would there be an
/etc/devfs.conf to be read? Would reading it have much less overhead than
reading /dev/?
> - 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.
This isn't already offered by /dev/?
> - 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.
Let it grow. Then people will know what truly New Technology we have.
I've got my 64 megs.
-rwxr-xr-x 1 root system 12137744 Nov 2 00:35 /vmunix
___
Trevor Johnson <trevor@jpj.org>