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