Re: [ANNOUNCE] block device interfaces changes

From: Alexander Viro (viro@math.psu.edu)
Date: Mon Jan 10 2000 - 16:15:38 EST


On Sun, 9 Jan 2000, Oliver Xymoron wrote:

> On Sat, 8 Jan 2000, Alexander Viro wrote:
>
> > and it works with external representation of object. Yes, both classes are
> > currently indexed by numbers. So? register_device() simply doesn't exist
> > and register_blkdev()/register_chrdev() have different types. For a good
> > reason.
>
> What reason was that? I rewrote it once to make both call a
> register_device which looked in a single hash table and it worked fine.
> Cut out a ton of pointless duplicate code.
>
> Forgive a brief digression into OOP-speak, but the way I see it, there
> should be an abstract base class called 'device', derived from an ABC
> called 'file'. So far, so good. Further, there should be an ABC subclass
> of device called 'block', which implements all the llrwblock type stuff.
> Again, so far, so good. But here's where the problem begins. Nothing
> outside of the drivers themselves should need know about anything below
> the device level of the hierarchy. And the only part that cares about that

Stop here. You just demonstrated that your classes hierarchy doesn't fit
the problem. In your model _all_ buffer cache code is a festering layering
violation. Block devices are not derived from file (let alone from a
bogus 'device' - show me a place where _that_ would be used. And recall
Occam's Razor). There is a constructor that takes a block device and makes
a file. That's it. BTW, there's a constructor doing the opposite -
loopback, that is. It's not a 'derives from' relation - what you have is a
pair of independent classes with conversions between them.

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



This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:16 EST