Re: Lots of SCSI-disks, how?!
Richard Gooch (Richard.Gooch@atnf.CSIRO.AU)
Thu, 23 Apr 1998 17:21:58 +1000
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?
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu