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
working
on the original AT&T version 6 source code, programming applications,
SysAdmin,
etc. I have administered HP file servers, Sun file servers, etc, with
multiple SCSI busses, and hundreds of hard drives. I did not like
Solaris
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
on,
what SCSI ID it has, move it to a new fileserver and it comes up with
the
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
> beautiful.
>
As others have pointed out.
To quote H. Peter Arvin:
<Begin Quote>
Auto device generation can be a security hole, and can be done in user
space without hogging tons of kernel memory.
<End Quote>
To quote H. Peter Arvin again:
<Begin Quote>
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!)
<End Quote>
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
performance hit.
Using either tar, or a C program to save and restore permissions,
user/group ownership, modtimes, etc is a hack.
To quote Theodore:
<Begin Quote>
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.
<End Quote>
-- 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 majordomo@vger.rutgers.edu Please read the FAQ at http://www.altern.org/andrebalsa/doc/lkml-faq.html