On Mon, 10 Jan 2000, Oliver Xymoron wrote:
> 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'.
Sorry, what are you smoking? If they are private members, _all_
local filesystems become ones too. Along with swap. Along with anything
that uses swap. E.g. shm handling. Or VM in general. And you are saying
that it's not a layering violation? Mind boggles... Just what is _not_ a
private member of blockdevice? pipes and sockets handling + (hopefully)
process management? Could you pass me that pot? Thank you.
> > 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.
Smashing major/minor is fine and it's in my queue. However, it's
_not_ the same as smashing b/c. Block devices are not subclass of files.
They are independent entities and they are used as such in a lot of
places. Trying to channel it through file interface is utterly bogus - try
to estimate the amount of layering violations and you'll see. What you
have is either a class derived both from file and block device _or_ a
constructor making former from the latter. Take your pick. I prefer the
second POV.
> > 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.
And? It implements device methods via calls of file ones (of underlying
file). Just as the glue code in drivers + block_dev.c implement file
methods via calls of block device ones (of underlying device). How it is
different?
-
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