Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 2 Oct 2006 13:23:50 -0400
From:      John Baldwin <john@baldwin.cx>
To:        freebsd-new-bus@freebsd.org
Subject:   Properly managing sub-allocations
Message-ID:  <200610021323.50997.john@baldwin.cx>

next in thread | raw e-mail | index | archive | help
I'm trying to cleanup a few things in apci and I ran into what I think is a 
new-bus architecture issue.  Specifically, acpi likes to allocate system 
resource resources from its parent, and then turn around and sub-alloc those 
out to children.  This mostly works fine except for the bus space details of 
the bus tag and bus handle.  Currently acpi(4) just copies the tag from the 
corresponding resource from the parent and sets the handle to the start of 
the resource.  This just happens to work currently because i386 and amd64 use 
the start of the resource for the handle for SYS_RES_IO and overwrite the 
handle in nexus_activate_resource() for SYS_RES_MEMORY.  This does add some 
ugliness though in that acpi needs to go find the parent resouce to copy the 
bus tag.  However, it's current algorithm wouldn't work in general (PC98 
needs to alloc bus handles, and it does so in nexus_alloc_resource() for 
example).

To solve this, I think we need to stop setting bus tags and handles in 
bus_alloc_resource().  One solution might be to add a new bus method to set 
those for a resource, but I think the better solution would be to set the bus 
tags and handles in bus_activate_resource().  It already sort of does this 
for some cases (SYS_RES_MEMORY on x86 for example) and will work with the 
existing ACPI model (it already passes up activate_resource to the parent, so 
we would just have to remove the explicit setting of the bus tag and handle).

I actually wonder if this isn't how things are supposed to be in the first 
place and that the current aberrations are just bugs?

-- 
John Baldwin



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200610021323.50997.john>