CGL and the Linux Foundation

[Joe.MacDonald@xxxxxxxxxxxxx (MacDonald, Joe)]

Hi Dan,

Just now catching up on a pile of mail from the last week, so some of
this will likely be out of order, but I really wanted to chime in here.

On Thu, 2007-10-05 at 23:48 -0700, Dan Kohn wrote:
> On May 10, 2007, at 11:28 PM, Takashi Ikebe wrote:
> 
> > I agree that.
> > Basically CGL is the Linux that applicable on carrier equipment.  
> > This means the CGL is different from general purpose Linux.
> > Network equipment typically requires high availability, real time  
> > capability (response time), serviceability than scalability and  
> > total throughput.
> > I think general purpose computing prefer latter.
> > Therefore I think the acceptance of community is hard because of  
> > carrier specific functionality. and that's why CGL exists.
[...]
> I would appreciate if you could provide some specific examples  
> (perhaps from the CGL 4.0 spec) of NTT requirements whose  
> implementations were explicitly rejected by the kernel community.

I think one of the things we want to keep in mind when we're talking
about CG requirements and whether they've been accepted into mainline or
not is that very few things are completely static in the kernel.  An
excellent example of this that I've been following closely over the past
couple of years has been the work by Con Klovias and more recently Ingo
Molnar on different schedulers.  Real time behaviour has already been
mentioned on the list (by at Takashi for sure and I think others as
well) and a related part of that is scheduler fairness.  Con's changes
were rejected several times and now it looks likely that at least some
version of his work will find its way into mainline.

One of the jobs of the CGL working group, in my eyes, is to be a forum
for discussing and coming to some sort of consensus on what features are
important to carriers, then representing those interests to the mainline
developers.  It's entirely possible that something that is important to
carriers may be diametrically opposed to something that is important to
desktop or data centre or mobile interests and would be rejected by
Linus et. al. until they are convinced of the merit of the feature in
question.

I think the new state of the world, with CGL and LSB and key kernel
developers all under the same virtual roof we have a great opportunity
for more effective communication than ever before and we should be
looking at CGL P1s (which were frequently nominated or supported as P1s
by SCOPE) which are not in mainline and determining how the PoCs can be
tweaked (or retooled or completely redesigned) in a way that will make
them acceptable.

> I am suggesting, however, a change in focus in CGL toward specifying  
> requirements (what and why) and away from specifying  
> implementations.  Further, I believe it is in the entire Linux  
> community's interest to avoid a fork.

I completely agree that a fork would serve no one's purpose, but with
the 4.0 specification we adopted a philosophy that it was reasonable
(and even necessary in some cases) to have a P1 with an implementation
that was outside mainline.  We rejected any P1, however, which wasn't
already in mainline or didn't have a reasonably well-maintained patch
set against a modern kernel.  I think that still fits with your
suggestion that we focus on requirements more than implementations, but
I think it's clear that in considering what level of priority to apply
to a requirement, it's critical to consider possible implementations.

-- 
Joe MacDonald <joe.macdonald@xxxxxxxxxxxxx>
Wind River Systems
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.linux-foundation.org/mailman/private/lf_carrier/attachments/20070515/a156ecfb/attachment.pgp