[cgl_discussion] CGL and DCL trees

Skip Ford skip.ford at verizon.net
Wed Dec 11 15:02:34 PST 2002

Randy.Dunlap wrote:
> On Wed, 11 Dec 2002, Skip Ford wrote:
> | Somebody has to maintain all the patchsets that will _never_ be accepted
> | at least by Linus and the tree that houses those patches is the real CGL
> | tree, and that's not what the current "-cgl" tree is.
> I mostly agree with you (except for the word "all" in "all the
> patchsets").  My vision of the cgl tree is very much like your
> description, and I said that in an email yesterday (or so).

But the word "all" is important IMO.  There may be many different
implementations of some of the features and they all need a home
for distributors to have a central source.  They will likely conflict so
a single tree would be tough to do, but it has to be done.

Why do you disagree with the word "all?"

> It's for patches above and beyond mainline that CGL needs, like
> LKCD, kmsgdump, etc.  Not only tools, but tools are a large part
> of it.  And (as I have also already said) I expect to have some
> experimental patches that come and go instead of staying in the
> tree for a longer time.

kmsgdump will likely make it into Linus' tree eventually.  He seems to
be working toward a unified dumping layer that coordinates mcore, kexec,
kmsgdump, netdump, and others.  So that should be in a non-CGL tree IMO.

As for LKCD, I know it's on your feature list, but I had in my tree for
a while as you know, and I finally just got rid of it.  I found it to be
slow and intrusive.  But I also don't think it'll be accepted so it has
to be in your cgl tree I guess.  I just wonder if it wouldn't be possible
to write a non-intrusive version that is only slow when you're actually
tracing that's based on kprobes.  Seems possible, but a lot of work.


More information about the cgl_discussion mailing list