In message: <[EMAIL PROTECTED]>
Ronald van der Pol <[EMAIL PROTECTED]> writes:
: On Wed, Jul 17, 2002 at 23:33:13 -0600, M. Warner Losh wrote:
: > It is a tiny piece of a larger puzzle that will be fixed as we do
: > proper resource allocation now that the BIOS specifications have been
: > changed by MS to move that into the OS.
: Can you elaborate on that or give some pointers?
Short answer: ACPI. :-)
Longer Answer: For some time now MS has had the notion of a Plug and
Play OS at the BIOS level. Most BIOSes had the ability to say "This
OS is a Plug and Play OS" and would refrain from assigning resources
to the pci cards that might be a pita for the PnP OS to deal with down
the road. In a Plug and Play OS, it deals with resource issues
compeletely and totally (except for devices required to boot the
system, iirc). In a non PnP OS, like FreeBSD, the OS expects the BIOS
to have assigned all the resources and activated all the cards.
For years, this worked great. ACPI can be viewed as an even more
extensive attempt to get the OS to assign all the resources to the
cards. Now with ACPI in more and more BIOSes, they are shipping w/o
the ability to turn off PnP OS. They assume that the OS will be at
least PnP, if not fully use the ACPI paradigm[*] to do its resource
thing. FreeBSD has to cope with this better in general.
PCI_ENABLE_IO_MODES is a kludge that only kinda makes things better.
NetBSD does a better job at this by enumerating things at boot time
and assigning resources when the big picture is being looked at.
FreeBSD should do this as well. We will have to deal with assigning
things that could need more resources later, like cardbus and cPCI
bridges, "big" chunks of space that they can later dole out as
needed. pci bridges make this problem more interesting because some
of them will only decode certain address ranges (which is the cause of
another kludge in the pci code).
You can do a web search for the pc99 design guide (and newer ones).
They go into some of this. The ACPI standards docs also go into this
as well, although the 1.0 verion didn't do it very well (imho). There
are a number of other places to look for information too. The
mindshare books might be good.
I'm not aware of one place the ties all of these "customs" together
into a coherent hole :-(.
[*] These are wesil words for "The OS does all the resource
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message