Messages in this thread | | | Date | Wed, 9 Jun 1999 17:47:01 +1000 | From | Richard Gooch <> | Subject | Re: Devfs, was Re: Migrating to larger numbers |
| |
Guest section writes: > From: Richard Gooch <rgooch@atnf.csiro.au> > > Guest section writes: > > From: Richard Gooch <rgooch@atnf.csiro.au> > > > > However, with devfs you can definately avoid the lookups into the > > major tables. Right now that's fast because they're simple arrays. If > > we go to 12 bit majors (or more), we're going to want to set them up > > as lists of some kind. And that means some kind of searching/hashing. > > And that's all for the benefit of finding our fops. Devfs completely > > avoids this overhead. > > > > No. A kdev_t is a pointer to a structure that has various fields. > > Not: > > blksize[MAJOR(dev)] > > but > > dev->major->blksize > > Cute. All, right, if you want to define kdev_t that way, go ahead. It > now has no relation to i_rdev. So once again we go through a lookup. > > I am not sure what you mean by `no relation to i_rdev'. > Indeed, i_rdev is of type kdev_t. > > Of course there is a lookup somewhere, namely at the moment > the device node is opened.
Exactly my point. The device number stored in the inode is just a number. Then you have to lookup the corresponding kdev_t structure. In fact what happens is we lookup by major. Right now with 8 bit majors we have a table. If we go to 12 or 16 bit majors, we'll have a list instead. So the lookup is no longer trivial. Devfs completely avoids this.
Regards,
Richard....
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |