CGL 5.0 - Git

[CMS063@xxxxxxxxxxxx (Smarduch Mario-CMS063)]

________________________________

From: lf_carrier-bounces@xxxxxxxxxxxxxxxxxxxxxxxxxx
[mailto:lf_carrier-bounces at lists.linux-foundation.org] On Behalf Of
Florian Heigl
Sent: Monday, May 19, 2008 9:04 AM
To: Greg KH
Cc: lf_carrier at linux-foundation.org
Subject: Re: CGL 5.0 - Git


Hi,

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. 
 
<Mario> No it was not submitted, after we scoped the effort required
to integrate in the kernel (i.e. and engage the community) 
Motorola dropped it. Regarding CGL features  I would agree with 
Florian there is all of stuff missing. This features 
alone is really like 10-15 gaps not one. In CG its not just simple as 
precise time measurement it goes way beyond that especially with 4G 
all IP based networks. In addition  there may still be critical gaps 
in precise memory accounting when user mlocked pages are used (common 
in CG environments). The latter  also impacts overcommit memory alg. 
Unfortunately developers and technicians (NEPs/Carriers)
are not aware of these issues and take for granted what tools like
SAR or vmstat tell them. In security space support for async hw based
crypto acceleration engines is not supported (as far as I know freescale
was working on this). Support for features like hardware assisted
IP filtering is not supported by iptables. IGMP snooping is not
supported
by ebtables. Support for hardware assited TLU units is not supported
(for example in routing). Overall there are still ways to go for CGL.
I would also say though that there are allot of
CGL features in the recent kernel where the common CG developer is
not aware off and they think a CGL distro is needed. I think that's 
one area where CGL & SCOPE has not provided guidance.

 

But in total there's probably still quite a few patches left.
kexec/kdump/netdump all
being mainlined by now the first thing I remember out of my head would
be EVLOG
which didn't get included because neither the posix draft standard nor
the posts
to lkml by telco admins or it's make as a plugin log mechanism were
convincing enough
to some people who thought structured logging must be bad. (ok, trust me
I do hate
AIX structured error logs, but anyway.)
another thing might be forced umount with process structure tear down
and this stuff.
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.

one note:
when I still tried to apply all the CGL patches that were relevant to my
non-telco system
I DEFINITELY wished for a GIT tree with a working, even if older,
version.
Probably this would also help with identifying the patches that need to
be revisited for
cleanly applying to the current upstream. 

Regards,
Florian