Martin, quoting Andrew:
appropriately modified CKRM, and a suitable controller.
So not CKRM as-is ...
Yes - by now we all agree that CKRM as it is doesn't provide some things that cpusets provides (though of course CKRM provides much more that cpusets doesn't.)
Andrew would ask, if I am channeling him correctly, how about CKRM as it could be? What would it take to modify CKRM so that it could subsume (embrace and replace) cpusets, meeting all the requirements that in the end we agreed were essential for cpusets to meet, rendering cpusets redundant and no longer needed?
I prefer the proposition that CKRM be modified so that individual instances run within each cpuset to the proposition that CKRM take over everything. In fact, I think that CKRM components that could be classified as "enabling technology" should be split out of CKRM as separate mechanisms and developed separately (possibly by the CKRM team) and that CKRM just be a client of these mechanisms. Otherwise there is a danger that these "enabling technologies" will be too specialized towards the needs of CKRM rather than being generally useful.
Peter -- Peter Williams [EMAIL PROTECTED]
"Learning, n. The kind of ignorance distinguishing the studious." -- Ambrose Bierce
------------------------------------------------------- This SF.net email is sponsored by: IT Product Guide on ITManagersJournal Use IT products in your business? Tell us what you think of them. Give us Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more http://productguide.itmanagersjournal.com/guidepromo.tmpl _______________________________________________ ckrm-tech mailing list https://lists.sourceforge.net/lists/listinfo/ckrm-tech
