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:3.359 / U:0.024 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site