lkml.org 
[lkml]   [1999]   [Jun]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.041 / U:0.164 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site