lkml.org 
[lkml]   [1999]   [Jul]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.176 / U:0.152 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site