[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20061030071838.7988d3e1.pj@sgi.com>
Date: Mon, 30 Oct 2006 07:18:38 -0800
From: Paul Jackson <pj@....com>
To: Pavel Emelianov <xemul@...nvz.org>
Cc: xemul@...nvz.org, vatsa@...ibm.com, dev@...nvz.org,
sekharan@...ibm.com, menage@...gle.com,
ckrm-tech@...ts.sourceforge.net, balbir@...ibm.com,
haveblue@...ibm.com, linux-kernel@...r.kernel.org,
matthltc@...ibm.com, dipankar@...ibm.com, rohitseth@...gle.com,
devel@...nvz.org
Subject: Re: [ckrm-tech] [RFC] Resource Management - Infrastructure choices
Pavel wrote:
> >> 3. Configfs may be easily implemented later as an additional
> >> interface. I propose the following solution:
> >> ...
> >
> Resource controller has nothing common with confgifs.
> That's the same as if we make netfilter depend on procfs.
Well ... if you used configfs as an interface to resource
controllers, as you said was easily done, then they would
have something to do with each other, right ;)?
Choose the right data structure for the job, and then reuse
what fits for that choice.
Neither avoid nor encouraging code reuse is the key question.
What's the best fit, long term, for the style of kernel-user
API, for this use? That's the key question.
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <pj@....com> 1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists