[cgl_discussion] CGL and DCL trees
rddunlap at osdl.org
Wed Dec 11 15:09:55 PST 2002
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]
More information about the cgl_discussion