Re: [PATCH 9/25] irq: Add a dynamic irq creation API

[ebiederm@xmission.com (Eric W. Biederman)]

Benjamin Herrenschmidt <benh@kernel.crashing.org> writes:

> On Tue, 2006-06-20 at 16:28 -0600, Eric W. Biederman wrote:
>> With the msi support comes a new concept in irq handling,
>> irqs that are created dynamically at run time.
>> 
>> Currently the msi code allocates irqs backwards.  First it
>> allocates a platform dependent routing value for an
>> interrupt the ``vector'' and then it figures out from the
>> vector which irq you are on.
>
> You may want to look at the work I'm currently doing for powerpc where
> we need a fully dynamic linux irq number allocation, completely separate
> spaces for hw numbers (vectors) and linux irq numbers for arbitrary PICs
> (and more than one in a given system) etc...
>
> I'll post a patch that shows the stuff I'm adding later today so you can
> have a look. There is some overlap with your dynamic irq stuff.
>
> I haven't completely ported all of powerpc to my new core yet which is
> why I haven't posted patches yet, but I'll have something out today.

Sure.  I know by the end of my patchset I have separated out hw numbers
from the linux irq numbers, so this should work for powerpc.
I would love to hear feedback on it though.

So to be very clear what we mean, because I have gotten bitten in the
past.  I understand the linux irq number to be:
a) An index in the irq_desc array.
b) An enumeration of the hardware interrupts sources.
c) Human visible so ideally it is neither arbitrary, nor
   very dynamic if the hardware is not.

Then there is the destination cookie (vector on x86) that is
available to the cpu when the interrupt is delivered.

I think we are on a similar track but I'm not at all certain I like
the idea of a fully dynamic linux irq number except in cases like MSI
where your sources are dynamic.   But I may be making the wrong
assumptions about what you are doing.

I think implementations where we expose the hardware cookie instead
of an enumeration of irq sources like ia64 does, impedes debugging
because the irq number will be different between boots, or loads
of the kernel module.  At the same time as long as we don't assume
the irq number is the hardware cookie I don't see any maintenance
problems with an implementation like that.

What I do know is that on x86_64 the multiple levels of translation
from the firmwares notion of the irq number to linux different
notion of the irq number made the code overly complex and fragile.
Which is one of the things I address in this patchset.

But I would be happy to have a look, and I very much
hope we can our implementations working together.

Eric