Messages in this thread |  | | Date | Sat, 2 Nov 1996 09:10:16 -0500 (EST) | From | Trevor Johnson <> | Subject | Re: dev |
| |
On Sat, 2 Nov 1996, Karl R. Heyes wrote:
> 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>
|  |