Re: Proposal for CORE components
tab-mTI/[email protected] (Vincent Hanquez) Sat, 28 Jul 2007 14:18:42 +0200
| Newsgroups | gmane.linux.cluster.openmosix.devel |
|---|---|
| Message-ID | <[email protected]> |
On Wed, Jul 25, 2007 at 03:21:13PM -0700, Jonathan Day wrote: > Here is my proposal for the CORE segment of the code. > The CORE segment is going to be the relatively stable > component of the code. Code in CORE would exist in two > states: viscous and locked-down. > > Viscous code would be code that is still changing - > it's still partly fluid - but changes relatively > slowly and only as needed. Glue layers between the > kernel and the CORE would be permanently viscous, as > the kernel's internal API is designed to change. The > initial drop into code would be entirely viscous. > > Locked-down code would be code where there is > sufficient confidence in it being complete and > sufficient for the current kernel AND in it being as > stable as can reasonably be achieved. Code should not > be marked as locked-down unless there's high > confidence in it. By implication, modifying > locked-down code should be avoided if possible, and on > modification it reverts to being viscous. > > The general concept is that the "real work" is largely > independent of implementation specifics of how the > data is passed in or out, that the CORE should only do > the generic, basic "real work" anyway, and that > everything else (ie: all the heavy lifting, the fancy > methods, experimental projects and the other code > that's going to be tough to write) can be attached > either directly to the viscous interface or to another > project if you need further abstraction. > > At this point, I simply do not know what would be > needed in the CORE component. Greater minds than mine, > however, exist on this list and can undoubtedly give a > clearer answer to this. > > I imagine that fundamental architecture-specific code > would reside in there - at least for architectures > that are actively-enough maintained that the code > could be viscous or locked-down. I imagine > universally-required helper functions would be there > too, but I'll leave that to the true kernel gurus here > to rule upon. This is by far the most vague proposal ever... you're proposing code to do stuff (not really clear what) that need to be locked-down (probably to do an API), and yet some viscous code to cope with linux evolution ... so in a nutshell, "creating an API on linux". why do that need to be describe in greater than 40 lines ? -- Vincent Hanquez ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/