> > Perhaps it should be considered splitting off a 2.2 kernel that
> > conforms to the old standard, and a parallel 3.0 version with the
> > resource management and other interface breaking code in it. Later
> > development will occur on 3.0 as 3.1. This provides a kernel (2.2) that
> > anyone can use and prepares everyone for 3.2.
>
> I think that would be even worse than the most dastardly of Andrew's
> plans. The whole issue here is how to maintain maximum compatibility, not
> how to splinter the kernel into more incompatible pieces.
The point of splitting is not to splinter, but to allow those who don't
wish to upgrade immediately a chance to think about it for a year or so.
The 2.2 in this case would be a dead end. Mods to 2.2 probably would
still be applicable to 3.0, as the only thing to be changed is the
resource management interface (though any changes involving that layer
are going to be a bit of a pain). In fact, 3.0 could be virtually
identical to 2.2 but for the interface (using macros in 2.2 for old
calls). The point is that the old interface stops at release 2.2.
-- William Burrow -- Fredericton Area Network, New Brunswick, Canada Copyright 1996 William Burrow This line left intentionally blank.