[cgl_discussion] configurable requirements - are they specified somewhere?

Craig Thomas craiger at osdl.org
Tue Oct 8 12:01:08 PDT 2002


Hey Mika, 

Thanks for coming by and providing your thoughts on
this matter.  I thought I'd share a summary with the rest of the
discussion list in order to close this matter.

In summary, it would be impractical to perform tests with some
requirements configured in and some out.  I agreed with this and
I wasn't trying to change that.  My point was that we have seen
build failures in the past where someone tried to configure out a
requirement by changing the config file.  I wanted to suggest that
we could run a series of compile tests to assure that this problem
would not occur.  Your point was that this was redundant work because
the distributions would configure the kernel a certain way and they
would be able to test this for us.

Another point you made was that if configurations were tested, then
where do you draw the line.  Its a lot like the story of an acclaimed
children's book: If You Give a Mouse a Cookie.  

Both these points are well made.  I guess we can let the distros play
with various configurations and let them figure out what the name/value
pairs need to be to get a requirement configured in our out.


On Tue, 2002-10-08 at 09:19, Craig Thomas wrote:
> On Tue, 2002-10-08 at 06:51, Mika Kukkonen wrote:
> > Errr... the definition of "configurable" is that the feature needs to
> > be active when the testing is made, but it can be _after_ that
> > deactivated using normal configuration and recompilation (changing
> > the source code is not allowed) to allow end-user to "configure out"
> > those features they do not want to use.
> > 
> > So given the definition above, I do not understand your
> > question/request, as from the testing point of view, there is no
> > difference between core and configurable features. You might want to
> > test the impact of configuring one or several of these "configurable"
> > features out, but IMHO that job should be left to the distribution
> > vendors.
> 
> The question arises from the deduction you made in the 2nd paragraph.
> A user of Carrier Grade Linux may not want Resource Monitor Performance,
> for example, and want to configure it out.  I don't necessarily agree
> that it is totally up to the distribution vendors to assure that all
> configurable requirements be tested by them.  Since the CGL working
> group has specified that some of these requirements are configurable,
> then the Proof of Concept should show that the projects introduced into
> CGL can be configured in or out, as stated by the requirements
> definition. In turn, the validation group should show that the
> requirement has been met (one part of a requirement should be to prove
> that it can be configured out). 
> 
> I totally agree that for a validation exercise, all of the requirements
> must be configured in and the tests run against the built kernel and
> user modules.  However, it would be embarrassing if the kernel panics
> with one or two requirements configured out. 
> 
> > 
> > --MiKu
> > 
> > On ma, 2002-10-07 at 17:22, Craig Thomas wrote:
> > > I was looking over the Requirements Definition version 1.1 document
> > > and I counted 45 requirements that are classified as configurable.
> > > This includes all priority 1, 2 and 3 requirements.
> > > 
> > > My question is:  Has someone put together the actual specification
> > > for the names of these configurable variable names and the possible
> > > values (OK, I realize they would be '=y' or '=n', in a config file, but
> > > I'm stating this for completeness)?  
> > > 
> > > Some of these are set as a boot command option, so these names and
> > > values would be helpful as well.
> > > 
> > > If someone has this information on a single cheat sheet, I would
> > > appreciate a copy of it.  Furthermore, I would think that this is a good
> > > thing to add to the Requirements Definition document under each 
> > > configurable requirement.
> > > 
> > > 
> > > -- 
> > > Craig Thomas                         phone: 503-626-2455  ext. 33
> > > Open Source Development Labs         email: craiger at osdl.org
> > > 15275 SW Koll Pkwy, Suite H
> > > Beaverton, OR  97006
> > > 
> > > _______________________________________________
> > > cgl_discussion mailing list
> > > cgl_discussion at lists.osdl.org
> > > http://lists.osdl.org/mailman/listinfo/cgl_discussion
> > 
> -- 
> Craig Thomas                         phone: 503-626-2455  ext. 33
> Open Source Development Labs         email: craiger at osdl.org
> 15275 SW Koll Pkwy, Suite H
> Beaverton, OR  97006
> 
> _______________________________________________
> cgl_discussion mailing list
> cgl_discussion at lists.osdl.org
> http://lists.osdl.org/mailman/listinfo/cgl_discussion
-- 
Craig Thomas                         phone: 503-626-2455  ext. 33
Open Source Development Labs         email: craiger at osdl.org
15275 SW Koll Pkwy, Suite H
Beaverton, OR  97006




More information about the cgl_discussion mailing list