cvs commit: src/sys/dev/cardbus cardbus.c src/sys/dev/pccard isa_common.c src/sys/kern subr_bus.c src/sys/sys bus.h

[Nate Lawson]

Warner Losh wrote:
> From: Nate Lawson <nate at root.org>
>>Great change.  One nit: the reverse order helped expose bugs in some 
>>resource allocation routines.
> 
> It did?  Which ones?  The rids weren't affected by the change, just
> the order that they were stored on the list.  And so far as I could
> tell, nobody depends on the order in the list for anything: everybody
> searches the list for the rigth rid to use.  I've not seen any
> evidence of this being the case, but maybe I'm forgetting something.

The acpi sysres code uses a list and walks through it to handle bad 
resources specified by the BIOS (i.e., overlapping in weird ways), see 
acpi_sysres_attach().  It's the only real user of rman.

The current code there depends on the order in one way:  when resources 
are wholly contained in each other, the first one allocated wins.  This 
should not have an effect in what we allocate but is an order dependency.

>>It might be nice to have some DEBUG 
>>option that inserted it at the head.  The backwards behavior actually 
>>triggered the bug you fixed in rman on various systems and might have 
>>lead us to it earlier if someone had run it down.  (Thanks for fixing 
>>that too.)
> 
> No.  The bug I fixed was due to the <second> time through the fdc
> allocation doing the wrong thing and gobbling up too many ioports.
> It would be there independent of this change.  Recall that the rid of
> the resource is in the struct resource_list_entry and that the
> standard subr_bus.c routines all search for a rid by value, rather
> than by list location.

The acpi sysres code did trigger this bug when users had a device which 
allocated a resource that overlapped rman and acpi.

-- 
Nate