[cgl_discussion] CGL and DCL trees
skip.ford at verizon.net
Wed Dec 11 15:02:34 PST 2002
> 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