[Fwd: Re: [cgl_discussion] Reposting my query about CGL-LSB
craiger at osdl.org
Fri Feb 14 09:52:39 PST 2003
From: Craig Thomas <craiger at osdl.org>
To: Subhabrata Biswas <subhabrata.biswas at wipro.com>
Subject: Re: [cgl_discussion] Reposting my query about CGL-LSB compliance
Date: Day, 14 Feb 2003 09:44:08 -0800
On Fri, 2003-02-14 at 04:49, Subhabrata Biswas wrote:
> > I guess at the time when 1.1 specs were made it was not yet clear to us
> > what our relationship with LSB really was, and so we played safe. But
> > fact really is that OSDL has neither will nor resources to start doing
> > LSB testing of distros, so we just have to rely on external parties
> > here.
> OK, Based on the information that all of you have put forth, one thing
> that's sure is that OSDL is no way concerned with LSB testing of distros.
> As you have mentioned Miku, you are relying on external parties
> to carry out LSB testing of the distros. Is it possible for me as an
> individual contributor or as a group to carry out this compliance testing
> activity. (Probably LSB team may have somthing to say on this as well, but
> I thought of getting the nod from OSDL-CGL team first.)
Basically, the OSDL CGL work group provides these functions:
1. A specification that defines the features necessary for Linux to
operate in a Carrier Grade environment (CGL specs group)
2. A collection of volunteers to drive these specification requirements
into the Linux kernel as main line or to provide user level code
if the feature is not kernel based (CGL Proof of Concept group)
3. A set of tests to support the acceptance of a CGL feature (CGL
As for LSB certification, you are correct that the work group does rely
on either an LSB certification brand or as mentioned by Jeremy, making
sure the LSB tests pass via a self-validation. I personally feel that
it is a good idea if you as an individual would like to run the LSB
tests on certain distributions that have CGL features, to assure that
no LSB regressions occur. As far as I understand the LSB and its tests,
the test suite is free to download and run by anybody (open). However,
only the LSB has the authority to _certify_ a distribution. Therefore,
you should be able to freely run the tests.
As far as carrying out the actual compliance testing, I think this is
more of an issue with the distributions than with LSB. You would need
to get their permission to speak on their behalf if you wanted to
publish whether or not a CGL distro was LSB compliant. (I'm not a
lawyer here, so this opinion may be incorrect).
> I'm interested in this activity because of two main reasons -
> The first (and the obvious one) is that I'm interested in contributing
> to CGL activites. Secondly my group members are already involved with
> the actual LSB activity in terms of writing specifications etc. So
> we were thinking that the our LSB knowledge and experience may just
> help us in contributing to this CGL-LSB and related activities.
One of the best ways to contribute to the CGL effort is to mimic what is
being done for the POSIX Interface compliant requirements (1.2.1 through
1.2.4). Here, a sourceforge project was created called the Open POSIX
Test Suite. Contributors are adding POSIX test cases to validate
compliance. It is hoped that in the future, the LSB will utilize these
test cases and incorporate them into their certification test.
That said, there has been some recent discussion to provide a similar
project for IPv6 validation tests. Investigations are underway to
determine the best method to deploy a test suite (heavily leveraging
the Tahi project). The goal again is to hope that these tests
eventually make it into the LSB suite in the future.
If you or your group is interested in contributing to CGL activities,
this would be the place to add the greatest benefit to CGL.
> There's also a doubt which I would like to get clarified, and I have
> seen similar opinions posted previously by Rusty and Stephanie as well.
> Supposing we find that adding the CGL patches to a previously "Compliant
> & Certified" linux distro causes new LSB failures, who is expected to
> take ownership of those? I am just curious to know OSDL-CGLWG stand on
So far, there should be no need for a CGL feature addition to change the
behavior of a core system call. Therefore, any CGL additions should not
affect the LSB compliance. However, in the event that an LSB regression
occurs, it should be up to the distribution first to assure that the
patches include were corrected. If the investigation of a regression
leads directly to a CGL feature, then the I would assume that the CGL
technical board will be involved in making some sort of decision
regarding the potential conflict between the LSB spec requirement and
the suspected CGL requirement causing the LSB regression.
> Looking forward to your views / suggestions on this.
> cgl_discussion mailing list
> cgl_discussion at lists.osdl.org
Craig Thomas <craiger at osdl.org>
Craig Thomas <craiger at osdl.org>
More information about the cgl_discussion