The Core and the Kernel

[Erik Walthinsen <omega@omegacs.net>]

> We can NOT have developers building new kernels that might make their
> stuff work but might break other things.

Right.  The goal of being Core-compliant (not SEUL-compliant, mind you), is 
to define a certain level of things that can be *assumed*.  If a commercial 
vendor were to build their application, say StarOffice, for Core version 
1.3, then that vendor should have the *right* to assume version A of the 
kernel (if that's an issue), version B of [g]libc, version C of this, 
version D of that.

Now, a given Core version will likely be three things: a document describing 
what is to be in the Core, a document describing what can be *assumed* of 
the core, and a reference implementation.  Very similar to what 86open will 
be doing.  They will produce a standard, and a reference implementation.  
Linux will use the reference implementation, most commercial Unices will 
simply be compliant.  However, I must stress the point that being compliant 
and being reference-based *must* be equivalent, from the point of view of 
someone reading the second doc mentioned above.

Back to the kernel for a little while: I don't think we should ship one 
kernel and require that everyone use it.  I think we should describe a 
*minimum* kernel, and a *minimum* set of extra patches (if we decide to do 
so) or equivalent functionality if said patches are later incorporated.  
That allows distributions to incorporate new kernels if they so choose.

OK, given that, here's my proposal for the naming scheme:

1) the Core documents (internal and external specs) will be versioned like 
any other program, i.e. 1.0, 1.1, 1.1.1, 1.1.2, 1.2, etc.

2) the Core *reference implementation* will be versioned based on the 
version of the Core documents, and an extra number for the implementation 
number.  Identical concept to what RedHat does with 2.0.32-2 stuff.  The 
version number defines what *external* functionality is provided, and it 
can be assumed that anything with the same version number but higher rev 
number is two things:
  a) identical or "better" external interface/specs
  b) a better implementation of those specs (i.e. better guts)

This means that for a given Core version, new reference implementations can 
be created as needed, while maintaining the same version number.  If 2.0.34 
comes out, you simply up the rev number.  This method also means that
"updates" can be released as patches to a given Core version-rev, without
breaking anything.  This IMO is a very good thing.

Comments?

     Erik Walthinsen <omega@seul.org> - SEUL Project system architect
        __
       /  \                SEUL: Simple End-User Linux -
      |    | M E G A            Creating a Linux distribution
      _\  /_                         for the home or office user