Messages in this thread | | | Subject | Re: New kernel/resource.c | Date | Fri, 16 Jul 1999 11:54:40 -0700 | From | Craig Milo Rogers <> |
| |
>> I've still got a laptop on my desk that doesn't have a PCI bus. ... >If it's the name you object to, then just don't call it PCI. Call it >"peanuts". ... >So instead of using confusing names like "peanut" or "pci_or_isa_or_ >pcmcia_or_who_the_hell_cares_what_electrical_bus_is_outside_the_cpu_ >as_we_cannot_see_it_anyway" , I'm just calling it "PCI". Fair enough? It's >99% of the interesting market these days.
Unless you are explicitly modeling the other busses as PCI variants (sorta like the IDE-to-SCSI emulation option), calling the general I/O resources "PCI" is misleading, confusing, and perhaps dumb.
It's misleading because it uses the wrong name for a concept. It's confusing, because newcomers to the kernel (and even more experienced hands) will misunderstand the semantics associated with "PCI" resources. Finally, it's perhaps dumb because it implies that PCI is the final bus, and a massive rename will be needed with we stransition to the next system bus (on the other hand, I appreciate the argument that the forced rename makes for a less buggy transition, so maybe it's not dumb).
Wouldn't it be clearer to call the two I/O resource spaces, say, ioport_resources and iomap_resources (ioremap_resources, iomem_resources, ...)? In my abjectly humble (hah!) opinion, this would be the Right Thing to Do.
>In particular, you don't have two resource trees for one and the same >resource. Also, you don't try to have a resource tree based on any >electrical hierarchy (ie you do NOT try to follow PCI bridges or whatever >that are largely invisible from a software standpoint). ... >What the peanuts actually are electrically you don't care about, because >you really cannot tell a difference.
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. Based on this information, you know what device drivers should perform an emergency shutdown, which is (I assert) a desirable thing to do. Therefore, you care about the electrical heirarchy. QED.
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.
I'd also like to address the problem of reserving resources for devices that don't exist (but might have existed in the past, or might exist in the future) (correct me if I'm wrong!). The general case of this problem is fairly difficult, and I can easily imagine that the conflicting constraints of different devices would not fit into a single resource allocation tree. Should these resource conflicts be managed in the kernel? Maybe; it might simplify some bootstrap issues, and some PNP configurations might require boot time kernel support.
FInally, on the issue of evolutionary vs. revolutionary changes in the Linux kernel. I appreciate the view of those who write, maintain, or use Linux kernel modules outside the main kernel tree; evolution if far better for them. However, the revolutionary changes that involve calling new subroutines (as opposed to calculating new expressions) seem to have been cleaner in the long run.
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/
| |