Carrier Grade Linux/Gaps Alpha1

[troy.heber@xxxxxx (Troy Heber)]

On 05/27/08 08:40, Greg KH wrote:

> Did anyone ever prove that if you implemented this, you would get faster
> boot times?  Or was it just a wild idea?

No, thats is why it is still a P3 requirement.

> I thought you all were moving away from the "accept a random feature
> requriement" to the more useful "accept a problem that needs to be
> solved" type model.

We are! And we are also trying to go through all of the old
requirements one by one and trying to reevaluate what we should do
with them.

> Except the fact that:
> 	- The overall boot time of a system shows that any potential
> 	  savings found by such an implementation is lost in the noise
> 	  of the test? [1]
> 	- The needed changes to properly implement this in a manner that
> 	  would be acceptable to "enterprise" customers would require
> 	  such massive changes, that no one has ever proposed a manner
> 	  in which they could possibly be done?

OK, I though the primary reason it was removed was because it simply
broke to many systems to ever be useful. I missed the results of the
benchmarking showing the whole concept was fruitless.

Obviously, give that bit of knowledge, this item should be deprecated
and removed from the gaps document.

> It's "nonsense" to have random wishlist items that do not explain why
> you feel you need this kind of thing, nor what it is really trying to
> achieve.

The issue we are dealing with is that a lot of these requirements were
contributed in the past. Rather than just throwing all of them out we
have been trying to work through them.

We are trying to do the right thing, moving to a model where we can
fully document key features that they need in the Telecom space. As we
are moving to the new model we still have gaps that people had
requested in the past.

Given each requirement it is challenging to find all of the relevant
history. This requirement is a good example of that. I was aware of
some of the work you did but did not have any knowledge that the
benchmarks showed no performance gain.

> Nor does it describe the work that had possibly been done in the past,
> the expected results, or the needed work that might be required to
> achieve such a thing (hint, one of the sentances in that requirement
> would entail such a massive rework of the module loading system and
> every single driver in the kernel that it's obvious no one realizes this
> is an unatainable fantasy for no real gain in the end.)

Again, given your extremely valuable insight into this area, it
becomes clear that this requirement should be deprecated. We are
really trying hard to clean up the requirements and move to a new
model that addresses the concerns you outline.

This is also why the gaps documents are currently marked as "ALPHA".
We are still trying to work through them cleaning them up as we go.

We would absolutely love to get your feedback on the other gaps listed
in the document! The more experts we can have giving us feedback the
better.

We did receive a lot of feedback on the gaps during the Linux
Foundation Collaboration Summit, although we have not yet had a
meeting to integrate that feedback into the documents. It really is a
work in progress.

We are absolutely open to any feedback we can get.

Troy