[lkml]   [1999]   [Jul]   [18]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: New kernel/resource.c
    On Sat, Jul 17, 1999 at 09:12:29PM +0300, Alon Ziv wrote:
    > >
    > > The reason for two resource trees for the same resource would be that one
    > > would contain some kind of "static rules" resource description, and the
    > > other one would contain the "current setup" resource description.
    > > Everybody basically agrees that you _do_ need to have both.

    It wasn't at all clear to me that you even agreed that we needed both.
    I'm glad we agree on that.

    > In my understanding of David's idea (I hope he'll correct me if I'm
    > wrong...), what he suggested was just that we use the same resource
    > manager internally by the various PnP support subsystems to maintain the
    > hardware hierarchies. The hardware hierarchies will be preallocated (if
    > needed); they may be used to route hotplug events, or to configure drivers
    > (if the drivers support this kind of `external cueing', which they _will_
    > need to do for proper PnP).

    I don't think so: I don't want the hardware tree to be internal to the
    PnP subsystem. It needs to be globally accessible: the "static" tree
    needs to have stuff put into it by PCI and PnP (and probably other
    things), and any hot plug subsystem needs to use it. I'm not really
    interested in using it to route hot plug events or manage driver
    bindings: I already have ways to do those things.

    Linus thinks one resource tree is the only way to go because we are
    conceptually describing a single resource. I think two trees are
    better, because the only parts of the kernel that care about the
    static info are hot plug bus drivers, and because putting this info in
    the same tree with the current info will be tricky. In an ideal
    world, it could be done cleanly because the static and current info
    would always be consistent with one another, and the static info would
    be complete. However, I know of enough exceptions, that I think the
    driver changes are not worth the effort. If someone comes up with a
    functionality argument for it down the road, they're free to do it.
    But it means the difference between a small job that I'd like to do to
    make PCMCIA work better, and a larger job that I won't do for no
    discernable benefit.

    Actually, there is a way to merge the trees that would not require a
    lot of driver changes: instead of two trees, use two types of nodes,
    "bus" nodes, and "driver" nodes. The resource calls used by drivers
    would treat bus nodes as invisible: you could allocate a region
    already spanned by a bus node (and that would add a node below the bus
    node), and regions would appear "free" if they were only allocated by
    bus nodes. This is similar in spirit to what my 2.3.6 resource
    changes did. You would need two sets of resource functions, one for
    use by bus drivers implemented like the current calls, and a separate
    set for device drivers that would hide the bus nodes. I guess that's
    nearly isomorphic with the two tree implementation, with more code, so
    it doesn't really seem worth it to me. But it gives you one data
    structure per resource.

    I do think there are enough conceptual differences between the two
    sorts of resources, that two trees are conceptually sound, aside from
    the coding arguments. The "current" tree is, as Linus has also said,
    strictly to arbitrate the inb/outb and readb/writeb interfaces between
    different drivers. The "static" tree is to arbitrate hardware routing
    of regions of address space for different devices, and while it might
    seem convenient to overload these onto the same tree, conceptually,
    they are not really the same thing.

    -- Dave

    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:53    [W:0.022 / U:98.772 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site