PF_HARDIRQ used in preempt-realtime-core.patch
I noticed that preempt-realtime-core.patch does this to hardirq.h:
-#define in_irq() (hardirq_count()) -#define in_softirq() (softirq_count()) -#define in_interrupt() (irq_count()) +#define in_irq() (hardirq_count() || (current->flags & PF_HARDIRQ)) +#define in_softirq() (softirq_count() || (current->flags & PF_SOFTIRQ))
+#define in_interrupt() (irq_count())
I was thinking that in order to have better patch bisection for future hard/softirq segmentation, that this chunk would be better suited to live in preempt-irqs-core.patch (where PF_HARDIRQ is introduced).
That would reduce the preempt-realtime-core.patch for hardirq.h to just one line, if we drop the whitespace shuffling in there at the same time.
I can send diffs of the existing 26rt9 patches, but I'm not sure how useful folks would find diffs of diffs (if any at all.). Since it doesn't impact the actual code base of the resulting patched tree, the other option is to just ignore it for 26 but keep it in mind for the future.
Paul.
Quoted 13 lines · Paul Gortmaker
I noticed that preempt-realtime-core.patch does this to
hardirq.h:(quoted diff) +3
-3-#define in_irq() (hardirq_count()) -#define in_softirq() (softirq_count()) -#define in_interrupt() (irq_count()) +#define in_irq() (hardirq_count() || (current->flags & PF_HARDIRQ)) +#define in_softirq() (softirq_count() || (current->flags & PF_SOFTIRQ)) +#define in_interrupt() (irq_count())I was thinking that in order to have better patch bisection for future hard/softirq segmentation, that this chunk would be better suited to live in preempt-irqs-core.patch (where
PF_HARDIRQis introduced).
Quoted 8 lines
That would reduce the preempt-realtime-core.patch for
hardirq.hto just one line, if we drop the whitespace shuffling in there at the same time.I can send diffs of the existing 26rt9 patches, but I'm not sure how useful folks would find diffs of diffs (if any at all.). Since it doesn't impact the actual code base of the resulting patched tree, the other option is to just ignore it for 26 but keep it in mind for the future.
Hi Paul,
at the risk of speaking out of turn here, I know that there is a history of cleanup attempts, that have not succeeded.
That being said, it might be in the best interest of avoiding wasted effort, or additional frustration, to keep cleanups as separate patches, at least until we have some kind of response from Steven or Thomas.
Sven
Quoted 5 lines
Paul.
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 27 lines · Sven-Thorsten Dietrich
Quoted 13 lines · Paul Gortmaker
I noticed that preempt-realtime-core.patch does this to
hardirq.h:(quoted diff) +3
-3-#define in_irq() (hardirq_count()) -#define in_softirq() (softirq_count()) -#define in_interrupt() (irq_count()) +#define in_irq() (hardirq_count() || (current->flags & PF_HARDIRQ)) +#define in_softirq() (softirq_count() || (current->flags & PF_SOFTIRQ)) +#define in_interrupt() (irq_count())I was thinking that in order to have better patch bisection for future hard/softirq segmentation, that this chunk would be better suited to live in preempt-irqs-core.patch (where
PF_HARDIRQis introduced).Quoted 9 lines
That would reduce the preempt-realtime-core.patch for
hardirq.hto just one line, if we drop the whitespace shuffling in there at the same time.I can send diffs of the existing 26rt9 patches, but I'm not sure how useful folks would find diffs of diffs (if any at all.). Since it doesn't impact the actual code base of the resulting patched tree, the other option is to just ignore it for 26 but keep it in mind for the future.
Hi Paul,
Quoted 3 lines
at the risk of speaking out of turn here, I know that there is a history of cleanup attempts, that have not succeeded.
Yes, I've seen some of that history and have no interest in repeating it. From the beginning I was trying to determine what would be the most use to folks, and trying to avoid anything that I thought could be in any way antagonistic to the folks doing the real work on RT.
Quoted 4 lines
That being said, it might be in the best interest of avoiding wasted effort, or additional frustration, to keep cleanups as separate patches, at least until we have some kind of response from Steven or Thomas.
I agree completely, and hence that was my original underlying goal with the carry forward -- to bring the patches forward in a form that kept them as
close to the originals as possible. Any new patches that I had to add in
order to get things to compile/boot I've kept as tail patches on the end, and I'll continue to keep them there.
I just wanted to give a heads up on this as I happened to notice it while reading over the patches, and since threaded IRQ support is a recent
area of interest. I'd feel guilty seeing it, but then just saying nothing.
If a 26rt10 appears with a change like this in it, then I'll make the same change in the carry forward patches I've done. Otherwise I'll leave things located exactly where they are in the carry forward series.
Thanks for the feedback, it helps me to know that I wasn't completely off base with my original thoughts of how to do something that might be useful in the end.
Paul.
Quoted 5 lines · Paul Gortmaker
Thanks for the feedback, it helps me to know that I wasn't completely off base with my original thoughts of how to do something that might be useful in the end.
I've pulled your patches into the preliminary openSUSE 11.1 RT Kernel so far.
I have to admit, a couple of the build fixes I did late night have not been pushed back; I'll sort through it asap, and I think Greg will have some patches for you to add as well.
It was my understanding that Thomas wanted to break into several git trees that had the different RT "features" broken out into several branches, and that makes sense to me.
Sven
Quoted 1 line
Paul.
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 11 lines · Sven-Thorsten Dietrich
Quoted 5 lines · Paul Gortmaker
Thanks for the feedback, it helps me to know that I wasn't completely off base with my original thoughts of how to do something that might be useful in the end.
I've pulled your patches into the preliminary openSUSE 11.1 RT Kernel so far.
Quoted 7 lines
I have to admit, a couple of the build fixes I did late night have not been pushed back; I'll sort through it asap, and I think Greg will have some patches for you to add as well.
It was my understanding that Thomas wanted to break into several git trees that had the different RT "features" broken out into several branches, and that makes sense to me.
I will finally have some time this week to start working on this. I may be peeking at the this git tree too. But first I just want to break everything out.
-- Steve