[GIT PULL] Disintegrate and kill asm/system.h

Grant Likely grant.likely at secretlab.ca
Fri Mar 30 08:14:42 EST 2012

On Thu, Mar 29, 2012 at 2:11 AM, Benjamin Herrenschmidt
<benh at kernel.crashing.org> wrote:
> On Wed, 2012-03-28 at 22:02 -0700, Linus Torvalds wrote:
>> On Wed, Mar 28, 2012 at 9:42 PM, Stephen Rothwell <sfr at canb.auug.org.au> wrote:
>> >
>> > How about this (build tested on powerpc allyesconfig):
>> Looks better.
>> Grant - what's the plan about that CONFIG_VIRQ_DEBUG thing? In theory
>> something like it could be useful as a generic thing, but at least
>> right now it is clearly powerpc-specific (not just that the config
>> option only exists for powerpc: it has that whole
>> 'powerpc_debugfs_root' thing in it)?
>> Stephen's patch very much looks like the right thing, but if there was
>> some plan to actually make this generic ...
> Yes, as I said earlier I think Grant should make it generic, there's
> no reason to keep that powerpc specific, it's fairly useful and nothing
> in userspace relies on the existing location of the debugfs file that I
> know about.
> Another option is to put the mapping information in /proc/interrupts but
> worry that changing anything in there (like adding a column) will break
> countless userspace tools.

I posted an RFC patch that does exactly that, but I'm similarly
nervous for the same reason:


The rightmost fields of /proc/interrupts are a weird set of
conditional outputs that don't really have any parsable formatting to
them.  It may be safe to apply my patch because it adds another field
in the middle of a section of conditional outputs* anyway so tools
already won't know what those fields mean.  But, regardless, I'm not
going to take responsibility for applying that patch unless encouraged
by several other maintainers to do so.

*It's added to the middle instead of the end purely for aesthetic
reasons.  The rightmost field is a freeform string without a field
width, so if put at the end they would never line up.  Suggestions for
a better layout are welcome.


More information about the Linuxppc-dev mailing list