From: Adam Belay <ambx1@neo.rr.com>
To: Len Brown <len.brown@intel.com>
Cc: linux-kernel@vger.kernel.org, greg@kroah.com, rml@ximian.com,
mochel@digitalimplant.org
Subject: Re: [RFC] Bus Resource Management
Date: Mon, 23 Aug 2004 20:00:31 +0000 [thread overview]
Message-ID: <20040823200031.GA7138@neo.rr.com> (raw)
In-Reply-To: <1093289962.17215.45.camel@dhcppc4>
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
prev parent reply other threads:[~2004-08-24 0:17 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-19 13:35 [RFC] Bus Resource Management Adam Belay
2004-08-23 19:39 ` Len Brown
2004-08-23 20:00 ` Adam Belay [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20040823200031.GA7138@neo.rr.com \
--to=ambx1@neo.rr.com \
--cc=greg@kroah.com \
--cc=len.brown@intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mochel@digitalimplant.org \
--cc=rml@ximian.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox