CGL 5.0 - Git

[tytso@xxxxxxx (Theodore Tso)]

On Mon, May 19, 2008 at 04:03:48PM +0200, Florian Heigl wrote:
> 
> as far as I can tell the carrier gaps document is far from complete
> in it's current state.  furthermore the precise process accounting
> patch is iirc a test on how to actually get the community convinced
> to commit something the CGL group needs, thus the extensive
> documentation. As I just lurk the CGL lists I dont know if it even
> was submitted to undertake that "test". if I recall correctly it had
> generated some attention but that seemed to have worn off.

If you try the latest Linux kernel from mainline, the recent tickless
scheduler and completely fair scheduler work means that elapsed CPU
time is *much* more accurate.  So if you schedule right after a clock
tick, the correct amount of time is correctly charged against the
process.  It doesn't necessarily give you microsecond level accuracy
(it depends on the accuracy of clocks provided by the hardware), but
is definitely good to milliseconds.  So this is probably one of the
places where the carrier gaps document is out of date.

> someone from montavista could probably list the things where they
> changed "panic" into "kill offending process" and in general I'd say
> it would be great if the CGL docs came back to the level of detail
> they use to have.

> on the other hand they used to have this and many, many of those
> patches they used were submitted to the linux community and i think
> a notable number didnt see inclusion not for code quality reasons
> but simply for being out of the ordinary.

> maybe it would help if the CGL current members pick some person who
> reevaluates all "useful" patches and then someone should go through
> them one by one and sort them, and eventually re-submit.

Let me gently suggest that putting this information into a "carrier
gaps document" is not the way to proceed.  What's necessary is for an
engineer to put this information in front of individual patches, where
each change should be separated into an individual patch, so they can
each be easily individually evaluated on its merits.  If you send a
single gargantuan megapatch, it will be ignored.  Secondly, the
patches need to be against the latest bleeding edge kernel, and not
something like 2.6.9 or 2.6.18.

That means doing some real engineering work and paying attention to
what's in the latest kernel.  And if you want to avoid a certain
amount of mockery and/or irritating patch reviewers, it's useful if
the engineer is tracking the mainline kernel well enough to realize,
for example, that even if the PPA patches mostly apply (with maybe
some changes to force-fit it), that it might not be necessary given
other changes that provide the same functionality (and more!  Green
Computing, anyone?) in a different way.

A git tree isn't necessarily the answer here.  In fact I'd probably do
it using an old fashioned patch queue, but the key is maintaining the
patches in a fine-grained manner with the explanation and
justification for each patch at the beginning of each patch, so it can
be sent to the LKML for review.  This is not documentation work; this
is engineering work.

Regards,

						- Ted