lkml.org 
[lkml]   [1998]   [Apr]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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.)

http://www.atnf.csiro.au/~rgooch/kernel-patches.html now has a link to
the devfs README, masquerading as a FAQ.

Regards,

Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

\
 
 \ /
  Last update: 2005-03-22 13:42    [from the cache]
©2003-2011 Jasper Spaans