Sure. I can certainly change the name to "ioport" and "iomap".
There are cases where people still do mixed-mode hardware (and "iomap"
might make sense for both their PCI side _and_ their "other" side), but
it's certainly so rare that I would not disagree with calling the "normal"
PCI/ISA/xxxx kind of thing ioport/iomap, and then some more BUS-specific
thing would do the "bus_mem_resrouce" (the way we now call it "PCI").
> I'm surprised by these claims; I'll attempt to disprove them.
> When dealing with hot-swap implementations (PCMCIA, SCSI, PCI, etc.),
> the electrical heirarchy tells you which physically related devices
> will be removed when a disconnection event is noted; for example, a
> PCMCIA card eject event for a multifunction PCMCIA card.
Note that the _conceptual_ hierarchy often has a physical reason behind
them. There is no question that the conceptual hierarchy (ie the one you
want to embed into the actual resource tree) is often mapped onto a
physical layout.
I'm saying that it's wrong to start with the physical layout and try to
"infer" some resources from that layout. I don't think you should try to
map the resources to PCI sub-buses, for example. I don't see the point in
having the PCI "ISA space" as a separate resource.
But conceptually the notion of "this area contains removable devices" _is_
obviously a hierarchy issue. No question of that. That's why I wanted to
make the resource control hierarchical in the first place.
I'm just saying that that issue actually has very little to do with the
bus. There might be a completely flat bus that has removable devices. Or
there may be a complex hierarchical bus that has partly removable devices.
The resource hierarchy should be concerned not with the physical layout of
the bus, but with the logical issue of "removability" for example.
> Should the electrical heirarchy be represented using the same
> generic resource management tools as the I/O port allocations?
> Perhaps, if it fits the problem; personally, I think that a simple
> tree structure would be more appropriate here. Should the kernel
> maintain it, or should it be in user space? Because of the
> interactions with the device drivers, I'd prefer a kernel solution, I
> think.
We want a kernel representation, but it should not be tied to the
electrical buses.
For example, the _physical_ network might look like this:
PCI ----+---- PCI-PCI +------ PCI card
| |
| |
| +------ PCI card
|
+---- PCI-PCI +------ PCI card
| |
| |
| +------ PCI card
|
+---- PCI-ISA +------ ISA card
| |
| |
| +------ ISA card
|
|
+----- PCI-PCMCIA ---- cardbus slot
and yet I see absolutely no reason to make the resource tree that complex
at all. The resource tree should probably just contain the top-level PCI
space, and the only real sub-tree would be a few PCMCIA trees (depending
on how the PCMCIA subsystem wants to partition the PCI address space)
This is why I don't think that the electrical stuff is all that important.
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/