lkml.org 
[lkml]   [1999]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: New kernel/resource.c
    On Thu, Jul 15, 1999 at 11:14:54AM -0700, Linus Torvalds wrote:
    >
    > You can have an arbitrary number of trees inside the PCMCIA code. One of
    > the goals I had was to never EVER care about what the resoruce allocators
    > were actually used for, and you can have "private" resources inside
    > PCMCIA.

    We are obviously not communicating. I sat down and wrote out another
    example of what I've already explained twice already, and I don't see
    how it would be any more clear than what I've already said.

    I want PCI and PnP code to preallocate resources for all hardware
    regardless of what drivers are loaded. I have code that does it. I'm
    not willing to rewrite the resource code in every driver in the kernel
    to make that work, when there is no need or benefit to doing so. Tell
    me how this information goes into the "one tree" in a way that PCMCIA
    can use it, without messing up anything else. With a separate tree
    for this information, it is trivial. I'm just taking all these new
    nodes that drivers won't care about anyway, and putting them someplace
    else.

    I see it as giving me 100% of what I want for 10% of the effort and no
    API changes. You say "one kind of information, one tree, period." If
    that's what you want, I guess that's the end of the argument.

    > My point is that there is one PCI resource, and that implies that there is
    > just one resource tree for PCI. Simple logic.

    The names "pci_io_resource" and "pci_mem_resource" should really be
    changed to be non-bus-specific, because they are not just PCI
    resources. I'd also disagree with your logic, because there is one
    set of resources from the perspective of hardware (i.e., a tree that
    represents how transactions are propagated after they leave the CPU),
    and one from the perspective of software (i.e., a tree describing how
    drivers interact with regions of CPU address space). The two can
    largely be superimposed, but you're representing two fundamentally
    different kinds of information.

    To give one example (there must be others), for some PCMCIA devices,
    the PCMCIA bus driver constructs an IO region by concatenating several
    bridge IO windows with different functional properties. From the
    hardware perspective, there are several IO resources in play: the
    windows can be configured and released independently. A client driver
    "sees" this as, functionally, just a single block of ports. How
    should this be represented in the resource tree? Does the client
    driver need to know that its one contiguous IO resource was actually
    implemented in a more complicated way by the low level hardware?

    -- Dave Hinds

    -
    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:53    [W:2.440 / U:0.108 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site