Re: Why not creating a GIT RT tree ?

[Steven Rostedt]

On Fri, 18 Jan 2008, Francis Moreau wrote:
> >
> > The answer to this is pretty much the same as why the -mm tree isn't in
> > git either.
> >
>
> Well not exactly. Unlike the mm tree which is made of a lots of patches
> dealing with totaly unrelated subjects, the rt patches only hopefully deal
> with realtime stuffs.

Well mostly realtime stuffs, but that's a lot of stuffs.

>
> > The RT tree is made up of lots of patches (over 300). Our goal is to get
> > RT into mainline Linux. RT isn't just one type of system, it extends all
> > over the kernel, and the patches may be rewriten over and over. Managing
> > this in quilt is a lot easier than managing it in git.
> >
>
> I'm probably missing something since I haven't looked at the RT patches
> (yet) but couldn't these 300 patches be sorted out by topics ?

They are, and different things bounce around a bit.

>
> If so you could create a branch per topic and merge all of them in your
> master branch which would be the rt kernel. Hopefully each branch
> won't interact with other branch too much.

That's the big problem, they do. <looks at the series>

Here's some of the stuff that's in the series (by topic)

 - Mcount tracing patches (touches things all over)
 - monotonic cycle patches
 - RT balancing patches (scheduled to go into 2.6.25)
 - KVM fixes (RT specific stuff for KVM)
 - A bunch of different arch stuff for timers (ARM, PPC, etc)
 - suspend / resume tweaks
 - various cleanups (some should probably go to mainline anyway)
 - latency tracer (also touches stuff all over)
 - lockdep tweaks
 - hrtimer tweaks
 - Preempt RCU patch queue (hopefully will go in 2.6.25 or 26)
 - softirq threading
 - hardirq threading
 - RT mutexes (turn spinlocks into mutexes - touches all over)
 - tasklet redesign
 - posix CPU timers
 - general realtime stuff
 - workqueue PI


And there's more. So I'm not sure how many branches would be needed, and
I could imaging it taking quite a bit. Again, this will be much more
difficult to manage then a simple quilt queue. When we get most the major
stuff in RT (threaded softirqs / hardirqs, and spinlocks to mutexes) then
it would probably be the time to create a git repo.


>
> All of this assumes of course that the number of topics is definitely much
> smaller than the number of patches (~300).

Smaller than 300, but much more than 10.

>
> Having such a tree would be very useful for looking at history in each topic,
> for doing some git-bisect debug session IMHO...

True, but then how would you do it. One thing is that most of these
branches would interact with each other. Touching the same code quite
a bit. So it doesn't always help. But pulling out patches can help us to
an extent.

> > That said, there's been talk about making a git tree for others based on
> > the quilt queue. The thing is that a new git tree will need to be created
> > for every release. Which means that it will be difficult for others to
> > simply update their local repo since you will get a bunch of errors with
> > not being from the same head.
> >
> >
> > >
> > > Another question, is there a TODO list somewhere which would
> > > help to port the RT patch to a new architecture ?
> >
> > Which arch? We are already on PowerPC, ARM and MIPS. Thinking about sh?
> >
>
> Yep, not that I'm an expert in this architecture but it's commonly used
> in multimedia device where realtime is often needed.

Great! Looking forward to it ;-)

-- Steve

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/