On 10/09/2009 03:42 PM, Arnd Bergmann wrote:
On Thursday 08 October 2009, Linus Torvalds wrote:
for some unfathomable reason. Quite frankly, I think Arnd just screwed up
the "generic" version, and the fix is almost certainly to just make the
generic version match all the main architectures.
I don't have any architectures using the generic header file, though, so
I'm not going to do that change blindly. People who do should look at it
(alpha, powerpc and mips look like the only ones that might be 64-bit, but
I didn't check very carefully - just grepped for it)
Added Cc's for some people that have worked on, or used, that generic
header file. Is there any possible reason why it is "unsigned long" in
that one?
It was intentional to make it unsigned long in the asm-generic
version, based on the observation that some of the 64-bit architectures
(alpha and parisc) were using unsigned long in their arch specific
files. The original parisc file contained
typedef struct {
unsigned long __softirq_pending; /* set_bit is used on this */
} ____cacheline_aligned irq_cpustat_t;
which would imply that unsigned int wouldn't work for it, and looked
like a good idea. It turns out that the comment is outdated, set_bit
hasn't been used on __softirq_pending on any architecture for a long
time as far as I can tell, and 32 bits is obviously enough for it.
Yes, I just tested it on the parisc architecture.
It seems we don't even touch this variable in our code.
The patch that Ralf just sent looks good therefore, but I'd suggest
either reverting two of Christophs patches that changed parisc and alpha
just to be on the safe side, or getting explicit Acks for Ralfs patch
from the maintainers of those two architectures.
Don't revert for parisc, as either "unsigned long" or "unsigned int" is OK.
So, Ralf's patch (switching __softirq_pending back to "unsigned int") get's my Ack:
Acked-by: Helge Deller <deller@xxxxxx>
Helge
--
To unsubscribe from this list: send the line "unsubscribe linux-parisc" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html