[lkml]   [1998]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Lots of SCSI-disks, how?!
    Rogier Wolff writes:
    > Richard Gooch wrote:
    > > >
    > > > Don't you? I didn't think that devfs removed the need for more space
    > > > in device numbers internally - I simply thought it made the user
    > > > interface far easier.
    > >
    > > When you call <devfs_register>, you pass an arbitrary pointer. When
    > > your driver f_op->open() method is called, filp->private_data is
    > > initialised with this arbitrary pointer. That effectively gives you a
    > > 32 bit minor number on 32 bit systems. You don't need to worry about
    > > the major number, because that is implicit in the f_op table you
    > > passed to <devfs_register>.
    > So, find is given the -xdev option. It stats all the files, and checks
    > to see wether the files are still on the same mountpoint as the
    > directories on the commandline.
    > So, tar is packing an archive, and it wants to detect hardlinks to
    > files that already are in the archive. To do this, it makes a list of
    > <devno, inum, filename> triplets for the files that it's already put
    > into the archive.
    > Richard, please explain to me why this is going to work on a libc5
    > based system?

    OK, please note that I'm not saying that we definately have to stick
    to 16 bit device numbers. My main point is that I think we can avoid
    increasing them if we so choose.

    Now to answer your question. Given that device numbers have no
    particular meaning for devfs, you could have devfs automatically
    assign a unique device number for each entry (that's a full 16 bit
    number). You could even restrict it so that only disc partitions get
    these automagic device numbers, if you wanted. That gives 64k
    partitions, which seems like a generous amount :-)

    Before you jump up and say that this would create a conflict with
    existing device numbers, I'll point out that when accessing a devfs
    inode the major and minor numbers are *not* used to find the driver
    f_op methods, so there's no chance of calling a random driver method.

    It seems to me that this should work OK. What do you think?



    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to

     \ /
      Last update: 2005-03-22 13:42    [W:0.020 / U:7.708 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site