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

[Warner Losh]

From: Nate Lawson <nate at root.org>
Subject: Re: cvs commit: src/sys/dev/cardbus cardbus.c src/sys/dev/pccard pccard.c src/sys/dev/pci pci.c src/sys/i386/i386 nexus.c src/sys/isa isa_common.c src/sys/kern subr_bus.c src/sys/sys bus.h
Date: Fri, 18 Mar 2005 11:25:52 -0800

> Warner Losh wrote:
> > imp         2005-03-18 05:19:50 UTC
> > 
> >   FreeBSD src repository
> > 
> >   Modified files:
> >     sys/dev/cardbus      cardbus.c 
> >     sys/dev/pccard       pccard.c 
> >     sys/dev/pci          pci.c 
> >     sys/i386/i386        nexus.c 
> >     sys/isa              isa_common.c 
> >     sys/kern             subr_bus.c 
> >     sys/sys              bus.h 
> >   Log:
> >   Use STAILQ in preference to SLIST for the resources.  Insert new resources
> >   last in the list rather than first.
> >   
> >   This makes the resouces print in the 4.x order rather than the 5.x order
> >   (eg fdc0 at 0x3f0-0x3f5,0x3f7 is 4.x, but 0x3f7,0x3f0-0x3f5 is 5.x).  This
> >   also means that the pci code will once again print the resources in BAR
> >   ascending order.
> >   
> >   Revision  Changes    Path
> >   1.52      +4 -4      src/sys/dev/cardbus/cardbus.c
> >   1.100     +1 -1      src/sys/dev/pccard/pccard.c
> >   1.282     +1 -1      src/sys/dev/pci/pci.c
> >   1.61      +1 -1      src/sys/i386/i386/nexus.c
> >   1.42      +5 -5      src/sys/isa/isa_common.c
> >   1.174     +7 -7      src/sys/kern/subr_bus.c
> >   1.67      +2 -2      src/sys/sys/bus.h
> 
> 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.

> 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.

There was one bug in the npx driver where it set start and end to the
same thing.  However, that's a bug in the bus_alloc_resource() call,
not a bug in the list handling.

Of course, if there's something I overlooked, please let me know.

Warner