lkml.org 
[lkml]   [1998]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: DEVFSv50 and /dev/fb? (or /dev/fb/? ???)
On Fri, 7 Aug 1998, Kragen wrote:

> On Thu, 6 Aug 1998, Stephen Frost wrote:
> > SUN has it's own problems w/ that damn /devices directory and the
> > fact that they use those names in their log files. I've discovered that
> > the /dev/dsk/c0t0d0s0 way of expressing a disk is VERY usefull in large
> > machines. Yes if you have all of one SCSI controller and maybe two drives
> > the /dev/sda solution is fine, but when you have 6 controllers and about
> > 30 drives, as well as a raid array w/ another 36 drives in it, I'm sorry,
> > but /dev/sda would not cut it.
>
> Maybe we could have the best of both worlds:
> /dev/sda is /dev/dsk/c0t0d0*
> /dev/sda1 is /dev/dsk/c0t0d0s0
> /dev/sda2 is /dev/dsk/c0t0d0s1
> /dev/sda3 is /dev/dsk/c0t0d0s2
> /dev/sdb1 is /dev/dsk/c0t1d0s0
> /dev/sdb2 is /dev/dsk/c0t1d0s1

I'm not sure how dev_fs works, but if I understand correctly,
it provides for backwards compatibility already...

>
> -- which gives us the same simple names we have now (only stable!) --
> and the naming scheme can be extended uniformly to more complex
> setups:
> /dev/sd_c1_a1 is /dev/dsk/c1t0d0s0
> /dev/sd_c1_a2 is /dev/dsk/c1t0d0s1
> /dev/sda_d1_ is /dev/dsk/c0t0d1*
> /dev/sda_d1_1 is /dev/dsk/c0t0d1s0
> /dev/sda_d2_1 is /dev/dsk/c0t0d2s0
> /dev/sd_c2_d_d2_2 is /dev/dsk/c2t3d2s2

I don't really see the point in using /dev/sd_*, if I understand
correctly it isn't currently supported that way and, well, at least to me
it looks ugly, if we're going to do something new, let's just do it right.
Using /dev/sd_* just makes it look like the old way of doing things, but
it wouldn't be for backwards capability so at least in my view I think it
would be rather silly and pointless.

> I think easy things (remembering the names of the disks on a machine
> with one or two disks) should be easy, and hard things (having 100
> disks on one machine, adding and removing disks without having to edit
> fstab) should be possible.

I would agree w/ that, and as I mentioned, I had thought that
you could do that w/ dev_fs... Am I incorrect?

> The only disadvantages I can see to this scheme are that it requires a
> little bit more complexity (a couple of conditionals) in the code that
> creates these disks, and it requires a bit more complexity (the same
> couple of conditionals) in any user-level code that wants to traverse
> all possible disks. (But I suspect most such user-level code will just
> glob /dev/sd*.)

Quite possibly, and my feeling is that if it didn't work
previously (ie: /dev/sd_*) then why worry about it? I think dev_fs
should be backwards compatibile, but I also feel it foolish to try
and continue developing an old standard when there is a nice new
one already here.

> (Stephen proposed something similar in the message to which I am
> replying.)
>
> I must have missed the explanation of how autoloading of device-driver
> modules works with devfs. If a device is to be automatically loaded
> and configured when someone tries to access it, and devfs creates names
> in /dev as devices are loaded and configured, then how do you try to
> access the unloaded, unconfigured device?

Don't quite follow, no clue how that is handled.

> (I think devfs is a really good idea. But I like Plan9, too.)

No clue what 'Plan9' is...

> I DBA'd Informix for a while. It doesn't like it either. (In fact, it
> marks the space as "down" if it happens to start when it's
> inaccessible, and the only way to fix it is to restore the database
> from backup, or to have Informix support people telnet in and edit your
> root dbspace with a hex editor.)

Ouch, that sounds a bit like what Oracle would do, but I've never
had someone from Oracle attempt and such feet...

Stephen


-
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

\
 
 \ /
  Last update: 2005-03-22 13:43    [W:1.961 / U:0.068 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site