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