Messages in this thread | | | Date | Wed, 14 Jul 1999 17:40:00 -0700 | From | David Hinds <> | Subject | Re: New kernel/resource.c |
| |
On Wed, Jul 14, 1999 at 04:38:24PM -0700, Linus Torvalds wrote: > > I don't see the point. > > A PCMCIA card has to allocate its resources from within the PCMCIA region. > So it makes tons of sense to just say so. So a PCMCIA driver would do > > request_resource(&pcmcia_io_resource, &my_io_resource); > > while a "direct" PCI driver would use > > request_resource(&pci_io_resource, &my_io_resource);
Each PCMCIA socket has multiple independently configurable IO windows that can be placed anywhere (subject to constraints imposed by the card), so there can't be a global pcmcia_io_resource.
Consider: I insert an IDE PCMCIA device. It is configured with a single 16-port IO window: inside that 16-port block is the 8-port data region and a separate control port. I've got to allocate a 16-port block of IO space, then tell the IDE driver how to deal with it. The ide_register() interface asks for port #'s for the data and control ports. I'd need to change the interface to
ide_register(&ide_data_resource, data_base, &ide_control_resource, control_base)
(all these are necessary, because the two IO regions may or may not be in the same contiguous IO window, and offsets of the IDE registers within these regions are also not fixed). All such interfaces need to be updated.
Consider: we tweak the PCI subsystem to preallocate all PCI IO regions so that hot swap configuration won't cause collisions. Now all PCI drivers need to be updated to allocate their resources from their own device specific resource nodes, not from pci_io_resource. With two trees, drivers wouldn't be aware of the preallocation, but hot swap code could still use that information.
Consider: we add a PnP device enumerator, which gets resource tables from the BIOS for legacy devices. If we put this in our one global IO resource tree, then all ISA drivers need a way to traverse the tree to find the resources for their devices: we don't have a convenient place like pci_dev to put this information, and we also don't even have a convenient way of uniquely identifying ISA devices like PCI device ID's. Again, this sounds like a fairly major driver rewrite and a major kernel API change.
Two separate trees occupy exactly the same amount of space (modulo an extra tree head) as a unified tree. And they allow these changes to be made in stepwise fashion without immediately requiring every device driver to be updated.
To be clear, I'm comparing these two models:
Model 1:
- root IO: 0x0000-0xffff - PCI dev 0.00 base 0: 0x0100-0x01ff - eth0: 0x0100-0x01ff - PCI dev 0.00 base 1: 0x0200-0x02ff - eth0: 0x0200-0x02ff - ISA dev 00: 0x02f8-0x02ff - ttyS1: 0x02f8-0x02ff ...
Model 2:
- driver root: 0x0000-0xffff - eth0: 0x0100-0x01ff - eth0: 0x0200-0x02ff - ttyS1: 0x02f8-0x02ff ... - hardware root: 0x0000-0xffff - PCI dev 0.00 base 0: 0x0100-0x01ff - PCI dev 0.00 base 1: 0x0200-0x02ff - ISA dev 00: 0x02f8-0x02ff ...
If we do the two trees, we can later migrate to a single tree if we decide to do that. I agree with you that ultimately, a single tree is what we want: I just see having two trees as an easy way to transition to the new resource management scheme (costing only a few bytes) without requiring that a large number of things be rewritten.
-- Dave
- 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/
| |