On Mon, 10 Jan 2000, Alexander Viro wrote:
> 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.
There's no layering violation - the buffer cache code is by definition in
the set of code that knows about block devices. Effectively, that code is
a set of private member functions of 'blockdevice'.
> 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).
fs/devices.c is (or was) an obvious place to start. Note, my goal is not
just to erase the distinction there between block and char, which is
fairly trivial, but between major and minor as well. My aim is flatten the
"address space" so that you can make arbitrary registrations (similar to
what CIDR did to IP). I really don't have a problem with your block_device
approach, except that register_dev, open, and inode shouldn't be forced to
know about it.
> 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.
I don't know if that analogy flies. Loop is more like a pipe with a 'file'
and a 'blockdevice' as endpoints. Loop isn't historically a good example
of anything, though.
-- "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/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:16 EST