Proposal for CORE components

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.

Elsewhere, I've talked about reliable multicast and
other such methods. Those would very definitely be in
the realm of extensions. They would shape how a given
OpenMosix system would work, but would not be
fundamental to getting it to work at all. You don't
need the truly fancy stuff to get a basic system to
run.



       
____________________________________________________________________________________
Be a better Globetrotter. Get better travel answers from someone who knows. Yahoo! Answers - Check it out.
http://answers.yahoo.com/dir/?link=list&sid=396545469

-------------------------------------------------------------------------
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/