I can only answer for myself, and what you suspect, at least in my case,
is incorrect. I have been involved with UNIX for over 20 years, from
on the original AT&T version 6 source code, programming applications,
etc. I have administered HP file servers, Sun file servers, etc, with
multiple SCSI busses, and hundreds of hard drives. I did not like
then and still do not.
By contrast I have also administered large scale AppleShare file servers
with multiple SCSI controllers and nearly 64 drives.
Volume naming is nice. Does not matter care what SCSI controller it is
what SCSI ID it has, move it to a new fileserver and it comes up with
same name as before.
> Personally I really like DEVFS. It solves some real problems and it does
> it in a scaleable, forward-looking manner. Auto-generation seems like
> a quick-and-dirty hack by comparison. The counter-arguments I've seen
> seemed to mostly refer to vague aesthetic issues. I think the aesthetics
> of this kind of thing flow from its functionality, and by that DEVFS is
As others have pointed out.
To quote H. Peter Arvin:
Auto device generation can be a security hole, and can be done in user
space without hogging tons of kernel memory.
To quote H. Peter Arvin again:
Counter question: how much kernel memory does it take to
keep a million devices with all their info (atime, mtime,
ctime, permissions, ownership all included!)
Note no one from the dev_fs side has answered this question yet.
dev_fs uses too much of kernel memory and by doing so inflicts a
Using either tar, or a C program to save and restore permissions,
user/group ownership, modtimes, etc is a hack.
To quote Theodore:
As far as searching a list when we open a major number, again this is a
extremely flawed and weak argument. First of all, the vast majority of
systems out there will only have less than 16 major devices. A typical
system has less than 10 major devices. (cat /proc/devices and see!) So
searching the list is simply not a problem. If searching the list were
an issue, there are plenty of ways of solving this problem internal to
the kernel, without needing to make any user-visible changes --- such
using hash table.
-- Terry L. Ridder Blue Danube Software (Blaue Donau Software) "We do not write software, we compose it."
When the toast is burnt and all the milk has turned and Captain Crunch is waving farewell when the Big One finds you may this song remind you that they don't serve breakfast in hell ==Breakfast==Newsboys
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to firstname.lastname@example.org Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html