> > which populate the "inode->dev" union pointer, which in turn is _only_
> > a cache of the lookup. Right now we do this purely based on "dev_t",
> > and I think that is bogus. We should never pass a "dev_t" around
> > without an inode, I think.
> I doubt it. First of all, then we'd better make i_rdev dev_t. Right now
> we have it kdev_t and it makes absolutely no sense that way.
In fact, the whole "kdev_t" makes no sense if we have proper char_dev and
We have "dev_t" which is what we export to user space. And if we split up
char dev and block dev (which I'm an avid proponent for), kdev_t will be
> The real thing is inode->dev. Notice that for devfs (and per-device
> filesystems) we can set it upon inode creation, since they _know_ it
> from the very beginning and there is absolutely no reason to do any
> hash lookups. Moreover, in these cases we may have no meaningful device
> number at all.
Sure. If something like devfs _knows_ the device pointers from the very
beginning, then just do:
- increment reference count
- inode->dev.char = cdev;
> > Block devices will have the "request queue" pointer, and the size and
> > partitioning information. Character devices currently would not have
> Do we really want a separate queue for each partition?
But the pointer is not a 1:1 thing (otherwise we'd just put the whole
request queue _into_ the block device).
The block device should have a pointer to the request queue, along with
the partitioning information. Why? Because that way it becomes very simple
indeed to do request processing: none of the current "look up the proper
queue for each request and do the partition offset magic inside each
driver". Instead, the queuing function becomes:
bh->index = bdev->index;
bh->sector += bdev->sector_offset;
and you're done. Those three lines did both the queue lookup, the
"index" for the driver, and the partitioning offset. Whoa, nelly.
And THAT is why you want to have the queue pointer in the bdev structure.
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/