Re: Request for comments (kdev_t and friends...)

Linus Torvalds (torvalds@transmeta.com)
Fri, 26 Nov 1999 12:00:15 -0800 (PST)


On Fri, 26 Nov 1999, Oliver Xymoron wrote:
>
> But why would you want that? Block devices look just like char devices. If
> you compare all of the (blk|chr) functions in fs/devices.c, they're
> identical except for referencing different arrays.

But that's BECAUSE they cannot be different right now. Both block devices
and character devices are described by the same descriptor "dev_t", which
gets translated to the same type "kdev_t" - whether they are block or
character devices is irrelevant to those translations, and thus they have
to be the same.

So of course they look the same.

But that's something we want to change. We want to have the pointer to the
block request list available immediately, for example. We don't want to do
the current lookup stuff that we do on every block IO start (see
ll_rw_block.c and wince). We don't want to have a global block statistics
array with magic knowledge about how the minor numbers are allocated
(again see ll_rw_block.c and wince).

We want to have ONE structure per device, and we want to have a direct
pointer to that structure that is looked up _once_ on device open and then
used ever after. And we want to have /proc just walk the list of allocated
structures when somebody asks for statistics, instead of the current mess.

> Further, major and minor don't make much sense either anymore. Major
> should indicate a device type, with minor indicating an instance. But now
> there are multiple devices within a major (misc, mem) and devices that
> span majors (tty, scsi). So the terms are more or less arbitrary. So most
> of the kernel outside drivers themselves should treat device handles as
> opaque.

The major/minor stuff should never be used in a perfect world, except for
the initial lookup. After that, you would just have "index within this
controller" or something, and that depends on the actual hardware.

> I'm not sure about this. Imagine kdev_t was a pointer to fops or something
> similar. The use of this pointer (in the usual way of using fops) would
> imply that the device was open, which would imply that the device driver
> was still around. Then dev->close() is put(dev).

Umm.. Look at where "kdev_t" is used. It's embedded in the buffer cache,
for example. And right now those have longer lifetimes than open/close.

Of course, maybe the right thing is to just not do that. Not allow buffers
to survive the close of a device. In which case the "put()" can indeed be
done at close time.

Linus

-
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/