[cgl_discussion] CGL and DCL trees

[Randy.Dunlap]

On Wed, 11 Dec 2002, Skip Ford wrote:

| 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.

I don't agree that distros need a cgl tree to pull from at all.
They will find their own sources and do their own merging.
I don't expect them to use this cgl tree.

| Why do you disagree with the word "all?"

Well, it's too inclusive.  Like saying always or never.
It makes for a giant melting pot (more like a stinky pot).
That's not the goal.

| > 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.
[s/LKCD/LTT/ according to Skip]

-- 
~Randy