lkml.org 
[lkml]   [1998]   [Apr]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Lots of SCSI-disks, how?!
Date
From
Richard Gooch wrote:
>
> 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 :-)

Besides that you propose to turnover lots of device drivers (which now
themselves do something to get at the major/minor number.), this
might work.

It now turns out that "the work is already done" is not true as you
claimed before.

You'd have to add dynamic device number allocation (ask Peter for say
4 consecutive majors). Then you can allocate every partition a dynamic
major/minor (1000 partitions should be enough for a while. Either you
have lots of partitions or you have lots of disks, most likely not
both).

So now we have
mount /devfs/xxyyzz /usr
which uses a dynamic (16 bit) major/minor number.

Next we have a find /usr -xdev ... which gets that dynamic major/minor
number in every stat that it does...

But we still have the

unsigned int minor = MINOR(rq->rq_dev), unit = minor >> PARTN_BITS;

in do_request in ide.c .

Roger.

--
If it's there and you can see it, it's REAL |___R.E.Wolff@BitWizard.nl |
If it's there and you can't see it, it's TRANSPARENT | Tel: +31-15-2137555 |
If it's not there and you can see it, it's VIRTUAL |__FAX:_+31-15-2138217 |
If it's not there and you can't see it, it's GONE! -- Roy Wilks, 1983 |_____|

-
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    [W:0.725 / U:0.116 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site