Messages in this thread | | | Date | Mon, 10 Jan 2000 16:15:38 -0500 (EST) | From | Alexander Viro <> | Subject | Re: [ANNOUNCE] block device interfaces changes |
| |
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/
| |