So?
The resource allocator is designed so that you cannot add sub-resources to
things that can't cover them. That gives the 5-second clean implementation
to the problem rather than your ugly secondary setup:
allocate_pcmcia_resource(struct resource *res)
{
int error = -ENORES;
for (i = 0; i < pcmcia_resources; i++) {
error = request_resource(pcmcia[i], res);
if (!error)
break;
}
return error;
}
int free_pcmcia_resource(struct resource *res)
{
return release_resource(res);
}
and you're done.
> 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.
I'm not contesting that there may be interface changes.
However, I _am_ saying that I'm not going to add STUPID resource
allocators to the basline kernel just to avoid interface changes.
The current simple resources are clean and very expressive. You can
obviously do everything you need with them. If you want to do
pre-allocation, you can do that - you can just change your internal
resources at any time.
You could pre-allocate all your resources at bootup time, and then when
the pcmcia driver wants to re-allocate a region it just finds one of the
pre-allocated areas and then just changes the "name" pointer (and PCMCIA
can do all the resource tracking internally).
I gave you a clean interface. Leave it that way.
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/