> On Fri, 26 Nov 1999 Andries.Brouwer@cwi.nl wrote:
> >
> > But how is that different from the planned kdev_t?
> >
> > Your "struct block_device *" is precisely kdev_t.
>
> No.
>
> Notice that "kdev_t" implies that all devices have the same kind of
> pointer.
>
> "struct block_device" implies that, for example, character devices are of
> a completely different type.
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. I did this while adding
hashed device tables and the code got smaller. Pretty much the only
visible difference outside of a driver is that all block devices use
llrwblock. And since that's just part of its fops, it's not really visible
anyway. The line between block and char could easily be erased internally.
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.
> Also, the difference is in reference counting. The current setup assumes
> that you never have to "put" a reference to kdev_t, which is just broken
> in a dynamic environment - we do NOT want to be required to hold on to
> "struct block_device" data structures forever, we need to also clean them
> up after they are no longer referenced by anybody.
>
> It's more of an evolution of kdev_t, and I agree with you 100% in that
> sense.
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).
-- "Love the dolphins," she advised him. "Write by W.A.S.T.E.."
- 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/