Re: [RFC] Device Resource Management

[Greg KH <greg@kroah.com>]

On Sat, Dec 11, 2004 at 12:45:09AM -0500, Adam Belay wrote:
> 
> Hi All,
> 
> This patch is a draft for the core infustructure of driver model based
> resource management.  Buses capable of dynamically allocating resources (such
> as PCI or pcmcia), and recent developments with linux ACPI support have
> incited the need for the kernel to keep track of system resources, and assist
> in the allocation process.  Eventually I'd like to move on to more complex
> problems like resource rebalancing.  This patch simply lays out some
> foundation.
> 
> We currently have some infustructure, but it is more or less incomplete.  For
> example, it doesn't show how resources and the devices that consume them are
> related.  Also it isn't flexable enough to track all types of bus resources.
> ACPI, PnP, and PCI have to allocate interrupts somewhat blindly because
> request_irq happens too late in the game, and really is used to register
> interrupt handlers, not track interrupt usage.

But the interrupts are assigned early in the process, right?  We still
need to do that.

> My implementation is not based on the existing "struct resource" stuff because
> quite frankly, even making small changes would break a large number of
> drivers.  Instead it uses "struct iores"  My hope is that we can gradually
> phase the old implementation out.

Ah, what's wrong with a little breakage :)

> With that in mind, I'd like to work out a solid new API, and would appreciate
> any comments or suggestions, both on the code in this patch and the overall
> design of the API.
> 
> A few issues need to be discussed.  The most important is probably how sysfs
> will display resource usage?  "struct kobject" is actually larger then "struct
> iores" so I don't feel very comfortable embedding it.  But, if a kobject based
> sysfs resource tree would be needed, then I'd be happy to implement it.  If
> not what would be a good alternative?  Does the user have to read resources
> from each device like one would with this current patch?

Why would it matter if we export this info to userspace?  Do any
userspace programs care about this information?

> This patch was only tested for compilation so it may have a few bugs/typos.
> Once again I'd really appreciate any comments or suggestions.

It looks good.  What's the main goals of this redesign (for those of us
who are old and forgot what you said at the last kernel summit...)

thanks,

greg k-h