[lkml]   [2000]   [Jan]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [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

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    Please read the FAQ at

     \ /
      Last update: 2005-03-22 13:55    [W:0.037 / U:3.124 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site