CGL and the Linux Foundation

[dan@xxxxxxxxxxx (Dan Kohn)]

On May 2, 2007, at 5:20 AM, Joe MacDonald wrote:

> You can probably see how this sounds a lot like the new  
> organization is
> primarily focused on helping people who produce the code first (which
> I'm all in favour of), then using LSB as the vehicle for standardizing
> Linux platforms and finally encouraging collaboration on largely
> desktop-oriented areas.

I agree that we should have used some non-desktop examples.

>> In short, we do think some things that CGL wants to see in
>> carrier-grade Linux could best be implemented as LSB modules.
>> However, there's lots of other work that the LF is supporting that
>> has nothing to do with the LSB.  In particular, if we can find
>> specific gaps in kernel or package functionality, we would be willing
>> to fund developers to write patches that would then be submitted to
>> those projects.
>
> I certainly wouldn't argue against something like this, but so far CGL
> hasn't been focused on gaps and adding functionality to the  
> kernel.  My
> understanding was that CGL's goal was to identify pieces that
> distribution vendors must have in order to be reasonably called  
> Carrier
> Grade.  That way when someone is picking a distribution to run on  
> their
> equipment, they have a reasonable expectation that any Carrier Grade
> distribution has a set of core functionality and they can made their
> decision on other criteria (vendor relationship / reputation, value  
> add,
> specific hardware support, etc.).
>
> The CGL 4.0 spec has roadmap items, saying these are things that  
> either
> the CGL group or other groups (SCOPE for example) have identified  
> as key
> but don't currently exist or can't reasonably be called stable yet.
> It's important to remember, though, that one of the key criteria  
> for any
> 4.0 requirement to be a P1 was that there had to be a freely- 
> available,
> portable, widely-accepted proof-of-concept implementation available
> today.
>
> Do you have specific things the CGL working group did that you can see
> as clearly separate from the goals of LSB?

My concern here is that the distros are generally trying to avoid  
carrying patches of functionality not in the mainline kernel.  So CGL  
requirements mainly depend on patch adoption by the appropriate  
kernel subsystem maintainer.

I think CGL could create both an optional LSB module of functionality  
expected in any carrier-grade Linux distribution and also a gaps  
document that lists a set of requirements not currently satisfied by  
modern Linux distros.

>         In practical terms, this means that the technology is shipping
>         in all major Linux distributions; has an ABI that is deemed
>         stable over the long term; and has sufficient demand for
>         inclusion among the key stakeholders.
>
> That's not exactly an opposing goal to CGL, but it's easy to think of
> areas where specific parts of the CGL spec would necessarily fall
> outside this scope.
>
> I think perhaps it would be worth defining the scope of CGL separate
> from LSB would be a good idea, based on the guidelines laid out for  
> the
> CGL WG when it was a part of OSDL.

The best practice requirement is for required modules.  Optional  
modules are different.  I hope you will give a carrier-grade LSB  
module a chance.  I believe we need a new workgroup process that is  
neither what CGL nor the LSB did before.

            - dan
-- 
Dan Kohn <mailto:dan@xxxxxxxxxxx>
COO, The Linux Foundation <http://www.linux-foundation.org>
<http://www.dankohn.com/>  <tel:+1-415-233-1000>