Messages in this thread | | | Date | Fri, 16 Jul 1999 22:56:33 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: New kernel/resource.c |
| |
On Sat, 17 Jul 1999, Tom Leete wrote: > > I was thinking that kernel/resource.c was a general distributed allocator of > ports, addresses, etc. & that it was also for USB, firewire, whoever needed > such things.
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/
| |