Re: PF_HARDIRQ used in preempt-realtime-core.patch

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Sven-Thorsten Dietrich wrote:
On Mon, 2008-10-06 at 15:49 -0400, Paul Gortmaker wrote:
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.


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.

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.

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [RT Stable]     [Kernel Newbies]     [IDE]     [Security]     [Git]     [Netfilter]     [Bugtraq]     [Yosemite]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux ATA RAID]     [Samba]     [Video 4 Linux]     [Device Mapper]

  Powered by Linux