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

    \
     
     \ /
      Last update: 2005-03-22 13:55    [W:3.888 / U:0.020 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site