The code in kernel/resource.c indeed _is_ meant to be used for anything.
That obviously doesn't mean that it is necessarily _suitable_ for
everything out there - it's definitely aimed for "regions of space",
whether that space is IO port space, memory space, or IO-mapped memory
space. Or any other kind of one-dimensional "extent resource".
The resource code itself is completely agnostic about what resource it
handles.
However, there are then specific resources: the actual descriptors that
are manipulated by the generic resource functions. THOSE have specific
meaning. The two central ones are right now called "pci_io_resource" and
"pci_mem_resource", and they are "central" only in the sense that those
two resources are all that the old code ever handled at all.
To the new code, they aren't really special at all. They just happen to be
two kinds of resources, and they are the ones that actually impact a lot
of people because they happen to be related to the most common IO bus out
there.
But the whole argument has kind of derailed into two components, and now
people are just arguing about the naming of those two resources. The
naming is really largely irrelevant, except I want those two resource
types to have specific enough names that it _is_ clear exactly what kind
of resource they are. There can be tons of other resources, but those two
resources should be clearly defined.
The naming I don't have all that strong an opinion of, except that it
should be specific enough. "PCI" may be _too_ specific, certainly the
feedback from people seems to imply that some people really hate that
part. But "bus" is not specific at all. Somebody suggested "ioport" and
"iomem", and that may be the way to go. I'd almost like a "pc" there too,
just to clarify that we're really talking about a PC-like IO region, not
about any random IO region.
The argument actually started from a non-naming issue: the issue of using
two separate resource trees to describe the same resources (so with two
different PCI resources - memory-mapped and IO ports - you would actually
have _four_ different resource trees: memory would have two, and IO ports
would have another two resource trees).
My personal (strong) opinion is that that does not make any sense,
although I can see how that temporarily might make it easier to maintain
old (and fairly crufty) interfaces.
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.
But I designed the whole resource tree very much so that _one_ tree can
actually contain the full information. That's what the "sub-resources" are
all about (although you can use them in other ways too). You can have the
"rules" as separate resource areas, and then the actual current resources
as "children" of the "rule resource".
So by using the hierarchical nature of the resource trees, suddenly you
only need one tree, and you can also be assured that there can be no
inconsistency between the "rule" tree and the "real" tree - because the
resource allocator code can actually enforce the rules. If they are two
separate trees, the resource allocator cannot enforce anything, because as
far as the allocator is concerned they are two different resources.
See?
Linus
-
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/