Re: Request for comments (kdev_t and friends...)
Martin Dalecki (dalecki@cs.net.pl)
Sat, 27 Nov 1999 02:14:59 +0100
Oliver Xymoron wrote:
>
> On Fri, 26 Nov 1999, Linus Torvalds wrote:
>
> > 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.
This is a flaw in the actual usage of minor/mojors instead of a flaw
in the split concept itself. Basically if there where eough majors out
there
in first place no body would bother to pin for example the IDE CD-ROM's
on
the same major as the IDE-HD, which is indeed a mistake.
> > 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.."
--
Marcin Dalecki
-
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/