Re: [RFC] Bus Resource Management

[Adam Belay]

On Mon, Aug 23, 2004 at 03:39:22PM -0400, Len Brown wrote:
> On Thu, 2004-08-19 at 09:35, Adam Belay wrote:
>
> > 2.) Sysfs user interface
> > - userspace applications can determine resource usage and
> > dependencies.
> > - userspace applications can disable and enable devices
> > - userspace applications can assign resources to a device
> > - userspace applications can pause the operation of a device, and
> > rebalance
> >   its resources
>
> I agree that run-time hotplug policy and re-balancing would all be very
> snappy from user-space - users should be in charge when setting policy.
> Heck, humans may even be needed to make some decisions regarding
> resource conflicts...
>
> But I'm wondering where the proper line is between that and the resource
> management that we have to do on boot before user-space exists.
>
> cheers,
> -Len
>

For the minimum, I'm leaning toward in-kernel configuration of devices needed
for boot and their parents. I would like to see features such as rebalancing
performed from userspace.  However, if there is a specific reason for this to be
in the kernel, I'd be happy to implement it.  Right now I'm just trying to
establish an infustructure that we can adapt to our needs.

Also there is the option of using initrd and further limiting the number of
devices that have to be configured before userspace is loaded.

When and how devices and their drivers should be configure for resources and
other settings is really a matter that needs to be discussed.  Do we want more
userspace involvement or less userspace involvement?  Also should the kernel be
able to operate independently of userspace in every situation?  One advantage I
see with userspace involement is that it would allow for a cache of previous
configuration settings.  This would make it possible to ensure that all devices
are configured consistently between boots.  It could apply not only to resource
settings, but also to driver settings currently handled by module params.  We
could even control the binding of drivers to devices.

Thanks,
Adam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/