[lkml]   [1998]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Lots of SCSI-disks, how?!
    David Woodhouse writes:
    > > David Woodhouse writes:
    > > > Richard.Gooch@atnf.CSIRO.AU said:
    > > > > I don't see how you could increase the size of i_rdev in the kernel's
    > > > > struct inode without breaking C library compatibility, since the
    > > > > library expects i_rdev to be 16 bits followed by i_size.
    > > >
    > > > Translate it on syscall entry/exit iff current->personality == PER_LIBC5
    > >
    > > > Given that most programs which require such low level access are
    > > > available in source form, it'll be rare that this overhead is
    > > > incurred - most processes which use the affected syscalls will be
    > > > recompiled with glibc.
    > >
    > > Once again, you don't have to do any of this at all with devfs.
    > 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, if you write your driver to pass this 32 bit value around, you can
    ignore the minor number in i_rdev and use the 32 bit value instead. Of
    course, this requires a driver to make use of this, but it requires no
    changes in userspace, or personality hacks. And using config options
    you can support devfs and non-devfs systems.

    > > > Add a second major # for the SCSI system, following one of the more sensible
    > > > schemes suggested. Keep the old major/minor numbers, but deprecate them in
    > > > much the same way as the cua devices.
    > >
    > > This does look a bit painful.
    > Perhaps, but it's not that bad, and similar things have been done
    > before, with the tty devices.

    It's just that is seems completely avoidable.

    > > So why not use devfs? The work is done.
    > Even with devfs, you need a sensible internal representation of the
    > device major and minor numbers, yes?

    No. You could write a driver that used 0 for its major and minor
    numbers, and instead used that aribtrary pointer I mentioned above.

    > How does devfs handle the case where
    > you've got a room full of SCSI drives, each with 63 partitions?

    Encode host,channel,id,lun,partition in those 32 bits I mentioned and
    just ignore the major and minor numbers.

    > devfs provides an extremely useful way of presenting the extended
    > devices to libc[45] programs, and also for making them usable
    > without an extension to ext2fs, but can it really remove the need
    > for a larger __kernel_dev_t, too?

    I believe it does. I think it is possible to remove all uses of kdev_t
    from the kernel and fill userland i_rdev with 0. Of course, it would
    take a lot of work, but it could be done.

    Even without changing all existing drivers, you could write all new
    drivers using devfs-only semantics, and just change those drivers
    which need a bigger minor number (SCSI discs) to use devfs. We could
    stay with a 16 bit kdev_t forever.

    > (I ask this without having studied the source or the README, for which I
    > apologise.) now has a link to
    the devfs README, masquerading as a FAQ.



    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.023 / U:5.816 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site