Messages in this thread | | | Subject | Re: New kernel/resource.c | Date | Fri, 16 Jul 1999 14:33:55 -0700 | From | Craig Milo Rogers <> |
| |
>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.
Hmmm... at least in the area of older ISA/PCMCIA systems, a PCMCIA cad, say a modem, could appear anywhere (that the card permits) in the ISA I/O space. In fact a single card could contain several different ranges of I/O ports, as well as memory address windows, DMA resources, IRQs. In this sense, the entire ISA bus is a "removable" area when PCMCIA is connected.
Part of the issue, I think, is that bundle of resources of differing types needs to be considered as a unit for certain types of operations beyond simple conflict detection. Consider some of the cruft in ISA configuration: a serial card might support COM1: I/O ports with a particular IRQ, and COM2: I/O ports with another IRQ, and not allow mix-and-match configuration. (Yuk, what an awful design!)
Consider a PCMCIA combo card, with a SCSI controller and an Ethernet controller (assuming such a combo were marketed), and a mix of disk, CDROM, and tape drives connected to the SCSI bus. When you eject the card, some entity needs to notify the Ethernet driver and the SCSI driver of the ejection event. The most reasonable basis to do this, I think, is some representation of the fact that they share the same physical slot. There's probably no relationship between the I/O port addresses used by these devices; they'll most like occupy disjoint ranges of IO port space, with other devices' ports scattered inbetween.
Continuing the example, the SCSI driver ought to be able to notify the disk, CDROM, and tape drivers of the disconnection event. It could do this on the basis of its own data structures. However, and this is speculation on my part (and other parties to this conversation might have more pertinent experience), it might make a lot of sense, from a system configuration and maintenance point of view, to keep a uniform kernel representation of the physical bus connections in the system.
I've read only a little about USB; doesn't it allow for multilevel heirarchical bus segments?
In summary, I see three distinct problems with different solutions:
1) a linear resource space allocation problem, that can be addressed by the proposed range-based resource allocator. (I/O ports, mapped I/O, IRQs, SCSI bus addresses, etc.?)
2) a disconnection event problem, that can be addressed by a (uniform?) representation of the physical connections between (some) parts of the system. Example: PCMCIA, USB?
3) a startup/connection event problem, that requires some yucky conflict resolution, a knowledge base of deceptive and defective components, a persistent representation of the preferred and reserved configuration elements for this particular system... it ought to be in user space, but some of it has to be in the kernel for bootup on some systems. (PCMCIA, ISA PnP?)
Craig Milo Rogers
- 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/
| |