Re: RFC: Resource Management (fwd)

Andrew Mileski (dmtech@magi.com)
Fri, 16 Feb 1996 09:18:44 -0500 (EST)


>> Improved Hardware Resource Management
>> =====================================
>> - All hardware resources (DMA, I/O, IRQ, memory) are allocated through
>> a common kernel API.
>> - Any number and mixture of resources, in any order, can be requested
>> or released in a single call.
>> - All resources in use are reported under the proc fs.
>
>When (in boot proccess) will this be availiable? I suggessest as early
>as possible.

Yes, it is available at boot - the memory structures are static
(about 4k) so it is available even before paged memory.

>> Share and Play Nice! - The Golden Rules
>> ====================
>> 1) Don't access any resource you haven't successfully requested.
>> This includes both READ and WRITE operations.
>
>What is the suggested policy to (re)allocate ressources needed to boot
>proper but not known to full extend? (You know, what I have in mind is
>the console/VGA stuff. If we allocate IO and memory space at boot (which
>is preferrable) for a detected VGA, we might fail if we know what
>hardware is present and request the same ressource again.

Don't bother to release a resource if:
- it is vital to the driver
- it is gonna be used "real soon"
- your device cannot be re-configured by software
The intent is to hopefully allow devices to share resources.

>One option
>would be we let this be allocated and access anyhow (violation of the
>rule above) or we ask the console driver to release and allocate
>again.)

Forbidden :-)

>Also, would the PCI auto-configuration be taken care of?

Hopefully - that is down the road, but in the plan.

>the plug and play (even ISA to some extend) BIOS'es did some work
>configuring the (PCI) cards - should each driver find out itself or
>might it ask "tell me where I have to be"... This would not work if the
>BIOS isn't P&P.

Whether you have a PnP BIOS is a 'config' option, and even if you
say 'y' to it, the existence of the PnP BIOS is checked.

>> Should the resource info table overflow, the request/release operation
>> succeeds with a kernel message. This is "A Bad Thing (tm)", and the system
>
>Why not linked lists (see below)?

It is a linked list, but in STATIC memory (see above). I don't think
it will ever overflow. Note that it works identically like the
current scheme, which hasn't caused anybody problems AFAIK with
only 64 regions/resource - the 256 default regions in the new code
are also shared among resources.

Thanks for the comments!

-- Andrew E. Mileski --

-------------------------------------------------------
Located in Canada's Capital: Ottawa! (EST)
mailto:dmtech@magi.com http://www.magi.com/~dmtech/