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/