Re: [uClinux-dev] Kernel 2.6 size increase

From: Tom Rini <trini@kernel.crashing.org>
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: Bernardo Innocenti <bernie@develer.com>,
	Willy Tarreau <willy@w.ods.org>, Christoph Hellwig <hch@lst.de>,
	uClinux development list <uclinux-dev@uclinux.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [uClinux-dev] Kernel 2.6 size increase
Date: Tue, 29 Jul 2003 16:06:57 -0700	[thread overview]
Message-ID: <20030729230657.GL16051@ip68-0-152-218.tc.ph.cox.net> (raw)
In-Reply-To: <1059518889.6838.19.camel@dhcp22.swansea.linux.org.uk>

On Tue, Jul 29, 2003 at 11:48:10PM +0100, Alan Cox wrote:
> On Maw, 2003-07-29 at 23:29, Tom Rini wrote:
> > 
> > Well, from Pat's talk at OLS, it seems like sysfs would be an important
> > part of 'sleep', which is something at least some embedded systems care
> > about.
> 
> sysfs is relevant for bigger systems but for small embedded stuff the whole
> PM layer is fairly "so what". At that level your hardware is tightly defined
> and you *know* the power management ordering. Policy becomes critical for 
> performance and gets done at a very fine grained level - things like waking
> up the flash for a read then turning it back off on a timer for example.

And wouldn't it be nice to have one 'policy enforcing tool' or whatever
that you feed it policy_desktop.txt, policy_embedded_in_my_fridge.txt or
policy_enterprise.txt ?

And while you know the ordering for your one board, it's not the same as
that other board there, nor that third board just behind you, and so on.
So getting passed in some sort of tree (or more correctly DAG) and
dealing with it with some more generic code sure sounds nice.

-- 
Tom Rini
http://gate.crashing.org/~trini/