Messages in this thread | | | Date | Fri, 7 Aug 1998 11:12:54 -0400 (EDT) | From | Stephen Frost <> | Subject | Re: 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
| |