Re: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)

Richard Gooch (Richard.Gooch@atnf.CSIRO.AU)
Wed, 5 Aug 1998 20:21:38 +1000


Terry L. Ridder writes:
> Chris Wedgwood wrote:
> >
> > > 1. Companies, clients, and I like the current naming conventions,
> > > and want to keep using the current naming conventions.
> >
> > The current nomencature sucks.
> >
> > I don't know why everyone wants to hold on to /dev/sda,b,c,d, etc.
> > its horrible and IMO probably makes more sense to tie the device to
> > the physical controler, bus, card, etc.
>
> Perhaps because of many years of dealing with Solaris
> (see David Luyer's posting concerning Solaris) and HP-UX?
> Going from /dev/sda1 to /dev/c0t3d0s4 (as an example) is
> precisely what companies are trying to get away from.

With Linux devfs you have the choice of which names you want to use.

> I just setup a Solaris box for a client less than a month ago.
> Solaris /dev is out right ugly. HP-UX /dev is also ugly.
> Nearly every HP workstation I have seen at a client site
> has dozens of symlinks from complex names to simple names.
> The HP-UX /dev directory looks "cluttered".

That's why I moved the new names to a subdirectory. My /dev is quite
*uncluttered* now. I like that.

> > For mounts, etc. moving when SCSI devices are added, changed, etc.
> > then update mount(8) to be smart with volume labels. I had a rough
> > version of this working at one point (only worked for ext2fs and swap
> > files which had been `tagged').
>
> Yes, this is a pain, but at this point I have come to work around it
> whenever a drive is removed.

I hope you'll understand that other people have different situations
and that it *is* a problem for them, and that you'll respect their
view. Why oppose devfs when it's an option anyway? It's not costing
you anything, and helps a lot of us.

Hey! I don't have a SoundBlaster card! Let's chuck out drivers/sound,
it's only used by bimbos anyway! You don't need a SB to do Real
Work[tm]. I've seen that kind of attitude here before, and frankly I
find it selfish.

> > > 2. What advantage does dev_fs offer us over the present system?
> > > Understand that we do not care about thousands & thousands of
> > > inodes in /dev, we do not care about directory searches being
> > > slow. So given that what are the advantages?
> >
> > Thousands - think millions or perhaps even more. Think tens of
> > controllers, tens of busses, hundreds of devices tens of LUNs and
> > tens of partitions.
>
> I was thinking more along the lines of an Intel box with three
> BusLogic BT-932's connected to SCSI expansion boxes, with each box
> holding 14 drives for a total of 42 SCSI disks.

I would hate to have administer such a system without devfs.

> > And - yes, many many inodes are a problem.
>
> I agree many inodes are a problem.
> It is that problem that we do not care about.
> There are various reasons for that attitude, which I will not go into.

Is it because you only care about your own pet ideas? Look, I'm not
trying to force you to even use devfs, and if you do use it, I'm not
trying to force you to use the new names. Please respect the
substantial number of us who *do* see a need for it. You are welcome
to configure it out of your kernels.

> > Not that I advocate devfs, but there is no denying it does sidestep
> > the issue quite nicely, but then again, there may be other
> > alternatives not so closely tied to the kernel.
>
> Alternatives are nice to have and alternatives need to be looked at.

Yeah, but the alternatives are arranged as one solution per
problem. Devfs is arranged as one solution for many problems. And best
of all, it's *optional*.

Regards,

Richard....

-
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