Hello,
Maybe I missed it but I'm wondering why GIT is not used for
the RT development ? I can't find a rt tree anywhere and all
new rt release spoke about a patchset to apply on mainline
kernels.
Another question, is there a TODO list somewhere which would
help to port the RT patch to a new architecture ?
Sorry if the questions are dumbed but I'm just new to this
project.
Thanks
--
Francis
On Fri, 18 Jan 2008, Francis Moreau wrote:
> Maybe I missed it but I'm wondering why GIT is not used for
> the RT development ? I can't find a rt tree anywhere and all
> new rt release spoke about a patchset to apply on mainline
> kernels.
The answer to this is pretty much the same as why the -mm tree isn't in
git either.
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.
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?
The best would be to read the code and look at my paper:
http://ols.108.redhat.com/2007/Reprints/rostedt-Reprint.pdf
(Internals of the RT Patch)
This will give you an idea of what is needed to port to another arch.
>
> Sorry if the questions are dumbed but I'm just new to this
> project.
No, in fact, I think it's about time to add these to our FAQ:
http://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions
Thanks,
-- Steve
Hello,
On Jan 18, 2008 4:55 PM, Steven Rostedt <[email protected]> wrote:
>
> On Fri, 18 Jan 2008, Francis Moreau wrote:
>
> > Maybe I missed it but I'm wondering why GIT is not used for
> > the RT development ? I can't find a rt tree anywhere and all
> > new rt release spoke about a patchset to apply on mainline
> > kernels.
>
> 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.
> 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 ?
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.
All of this assumes of course that the number of topics is definitely much
smaller than the number of patches (~300).
Having such a tree would be very useful for looking at history in each topic,
for doing some git-bisect debug session IMHO...
> 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.
Thanks
--
Francis
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
>>>>> "Francis" == Francis Moreau <[email protected]> writes:
Francis> I can't find a rt tree anywhere and all new rt release spoke
Francis> about a patchset to apply on mainline kernels.
It is not perfect, but I do have a git repo of the rt history-of-patches
up at:
git://git.kernel.org/pub/scm/linux/kernel/git/cloos/rt-2.6.git
http://www.kernel.org/pub/scm/linux/kernel/git/cloos/rt-2.6.git
Gitweb URL is:
http://git.kernel.org/?p=linux/kernel/git/cloos/rt-2.6.git
It is in the one-head per patch style, and has the single-file patches
applied rather than the quilt queue.
But it will at least allow comparisons among the various versions.
The master head matches the most current patch.
(I try to keep it updated the same day as patches are announced, but
it does sometimes lag a day or two.)
-JimC
--
James Cloos <[email protected]> OpenPGP: 1024D/ED7DAEA6
On Fri, 18 Jan 2008, James Cloos wrote:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/cloos/rt-2.6.git
> http://www.kernel.org/pub/scm/linux/kernel/git/cloos/rt-2.6.git
Thanks for doing this. We might want to add this to the wiki.
http://rt.wiki.kernel.org/index.php/Main_Page
-- Steve
On Jan 18, 2008 8:12 PM, Steven Rostedt <[email protected]> wrote:
> 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.
>
I see, it would probably be too painful in this context, that's pity.
>
> Great! Looking forward to it ;-)
>
Well actually it seems already supported. Some files in arch/sh
are already touched by RT patches.
I took a look to your interesting paper and I have now a question
about the BKL: Why is it so hard to get ride of it completely ?
Do you have any advices or starting point to get involved in RT kernel ?
I'm almost new in this area but I'd like to acquire some knowledges and
try to contribute if possible...
Thanks !
--
Francis
Hello,
On Jan 18, 2008 10:59 PM, James Cloos <[email protected]> wrote:
> >>>>> "Francis" == Francis Moreau <[email protected]> writes:
>
> Francis> I can't find a rt tree anywhere and all new rt release spoke
> Francis> about a patchset to apply on mainline kernels.
>
> It is not perfect, but I do have a git repo of the rt history-of-patches
> up at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/cloos/rt-2.6.git
> http://www.kernel.org/pub/scm/linux/kernel/git/cloos/rt-2.6.git
>
> Gitweb URL is:
>
> http://git.kernel.org/?p=linux/kernel/git/cloos/rt-2.6.git
>
> It is in the one-head per patch style, and has the single-file patches
> applied rather than the quilt queue.
Why don't you have one commit per patch ?
Thanks
--
Francis
On 1/18/08, Steven Rostedt <[email protected]> wrote:
>
> On Fri, 18 Jan 2008, Francis Moreau wrote:
>
> > Maybe I missed it but I'm wondering why GIT is not used for
> > the RT development ? I can't find a rt tree anywhere and all
> > new rt release spoke about a patchset to apply on mainline
> > kernels.
>
> The answer to this is pretty much the same as why the -mm tree isn't in
> git either.
>
> 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.
>
> 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.
stgit is worth checking out. It's basically quilt for git. I'm using
to juggle about 30 patches.
I believe there is a way to set up the git config file on the server
to force updating clients onto the new head without triggering an
error messages.
Ask on the git list and you'll get at least a dozen different
suggestions on how to make your repo available on git.
>
>
> >
> > 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?
>
> The best would be to read the code and look at my paper:
>
> http://ols.108.redhat.com/2007/Reprints/rostedt-Reprint.pdf
> (Internals of the RT Patch)
>
> This will give you an idea of what is needed to port to another arch.
>
> >
> > Sorry if the questions are dumbed but I'm just new to this
> > project.
>
> No, in fact, I think it's about time to add these to our FAQ:
>
> http://rt.wiki.kernel.org/index.php/Frequently_Asked_Questions
>
> Thanks,
>
> -- Steve
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
--
Jon Smirl
[email protected]
>>>>> "Francis" == Francis Moreau <[email protected]> writes:
>> It is in the one-head per patch style, and has the single-file
>> patches applied rather than the quilt queue.
Francis> Why don't you have one commit per patch ?
I started it before they had the broken out patches and haven't spent
the time to put together a process for the broken out patches akin to
what I figured out for the all-in-one patches.
In other words, intertia.
-JimC
--
James Cloos <[email protected]> OpenPGP: 1024D/ED7DAEA6
On Sat, Jan 19, 2008 at 08:41:18PM +0100, Francis Moreau wrote:
> On Jan 18, 2008 8:12 PM, Steven Rostedt <[email protected]> wrote:
> > 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.
> >
>
> I see, it would probably be too painful in this context, that's pity.
>
> >
> > Great! Looking forward to it ;-)
> >
>
> Well actually it seems already supported. Some files in arch/sh
> are already touched by RT patches.
>
At least it sees fairly regular testing on SH7751R and SH7780, you may
wish to discuss this with Matsubara-san (added to CC) though, as he does
most of the work in this area. I don't get much time to look at it.