On Fri, Oct 19, 2007 at 03:54:43AM -0400, Jeff Garzik wrote:
>
> The overwhelming majority of drivers do not ever bother with the 'irq'
> argument that is passed to each driver's irq handler.
>
> Of the minority of drivers that do use the arg, the majority of those
> have the irq number stored
On Fri, Oct 19, 2007 at 03:54:43AM -0400, Jeff Garzik wrote:
The overwhelming majority of drivers do not ever bother with the 'irq'
argument that is passed to each driver's irq handler.
Of the minority of drivers that do use the arg, the majority of those
have the irq number stored in
Thomas Gleixner wrote:
On Fri, 19 Oct 2007, Eric W. Biederman wrote:
Ingo Molnar <[EMAIL PROTECTED]> writes:
* Eric W. Biederman <[EMAIL PROTECTED]> wrote:
thanks for doing this.
Yes. keeping this alive is good.
The practical question is how do we make this change without breaking
the
On Fri, 19 Oct 2007, Eric W. Biederman wrote:
> Ingo Molnar <[EMAIL PROTECTED]> writes:
>
> > * Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> >
> >> > thanks for doing this.
> >>
> >> Yes. keeping this alive is good.
> >>
> >> The practical question is how do we make this change without
Ingo Molnar <[EMAIL PROTECTED]> writes:
> * Eric W. Biederman <[EMAIL PROTECTED]> wrote:
>
>> > thanks for doing this.
>>
>> Yes. keeping this alive is good.
>>
>> The practical question is how do we make this change without breaking
>> the drivers that use their irq argument.
>
> the
* Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> > thanks for doing this.
>
> Yes. keeping this alive is good.
>
> The practical question is how do we make this change without breaking
> the drivers that use their irq argument.
the get_irq_regs() approach worked out really well. We should
Jeff Garzik wrote:
Once that effort is done, everything should be in the 'trivial' pile and
not have the logic that you are worried about (and thus there would be
no need to add an additional branch to the error handling path).
er, s/error/irq/
the perils of a multi-threaded brain...
-
To
Eric W. Biederman wrote:
Yes. keeping this alive is good.
The practical question is how do we make this change without breaking
the drivers that use their irq argument.
This is why I'm taking it slow, and not rushing to get this upstream :)
I am finding a ton of bugs in each
On Fri, Oct 19, 2007 at 03:54:43AM -0400, Jeff Garzik wrote:
>
> WARNING NOT FOR MERGE WARNING NOT FOR MERGE WARNING NOT FOR MERGE
then whats the point ?
>
> This posting is just to demonstrate something that I have been keeping
> alive in the background. I have no urge to push it upstream
Thomas Gleixner <[EMAIL PROTECTED]> writes:
> On Fri, 19 Oct 2007, Jeff Garzik wrote:
>>
>> WARNING NOT FOR MERGE WARNING NOT FOR MERGE WARNING NOT FOR MERGE
>>
>> This posting is just to demonstrate something that I have been keeping
>> alive in the background. I have no urge to push it
On Fri, 19 Oct 2007, Jeff Garzik wrote:
>
> WARNING NOT FOR MERGE WARNING NOT FOR MERGE WARNING NOT FOR MERGE
>
> This posting is just to demonstrate something that I have been keeping
> alive in the background. I have no urge to push it upstream anytime
> soon.
>
> The overwhelming majority
WARNING NOT FOR MERGE WARNING NOT FOR MERGE WARNING NOT FOR MERGE
This posting is just to demonstrate something that I have been keeping
alive in the background. I have no urge to push it upstream anytime
soon.
The overwhelming majority of drivers do not ever bother with the 'irq'
argument
Ingo Molnar [EMAIL PROTECTED] writes:
* Eric W. Biederman [EMAIL PROTECTED] wrote:
thanks for doing this.
Yes. keeping this alive is good.
The practical question is how do we make this change without breaking
the drivers that use their irq argument.
the get_irq_regs() approach
Thomas Gleixner wrote:
On Fri, 19 Oct 2007, Eric W. Biederman wrote:
Ingo Molnar [EMAIL PROTECTED] writes:
* Eric W. Biederman [EMAIL PROTECTED] wrote:
thanks for doing this.
Yes. keeping this alive is good.
The practical question is how do we make this change without breaking
the
Jeff Garzik wrote:
Once that effort is done, everything should be in the 'trivial' pile and
not have the logic that you are worried about (and thus there would be
no need to add an additional branch to the error handling path).
er, s/error/irq/
the perils of a multi-threaded brain...
-
To
On Fri, 19 Oct 2007, Jeff Garzik wrote:
WARNING NOT FOR MERGE WARNING NOT FOR MERGE WARNING NOT FOR MERGE
This posting is just to demonstrate something that I have been keeping
alive in the background. I have no urge to push it upstream anytime
soon.
The overwhelming majority of
WARNING NOT FOR MERGE WARNING NOT FOR MERGE WARNING NOT FOR MERGE
This posting is just to demonstrate something that I have been keeping
alive in the background. I have no urge to push it upstream anytime
soon.
The overwhelming majority of drivers do not ever bother with the 'irq'
argument
On Fri, 19 Oct 2007, Eric W. Biederman wrote:
Ingo Molnar [EMAIL PROTECTED] writes:
* Eric W. Biederman [EMAIL PROTECTED] wrote:
thanks for doing this.
Yes. keeping this alive is good.
The practical question is how do we make this change without breaking
the drivers that
* Eric W. Biederman [EMAIL PROTECTED] wrote:
thanks for doing this.
Yes. keeping this alive is good.
The practical question is how do we make this change without breaking
the drivers that use their irq argument.
the get_irq_regs() approach worked out really well. We should do a
On Fri, Oct 19, 2007 at 03:54:43AM -0400, Jeff Garzik wrote:
WARNING NOT FOR MERGE WARNING NOT FOR MERGE WARNING NOT FOR MERGE
then whats the point ?
This posting is just to demonstrate something that I have been keeping
alive in the background. I have no urge to push it upstream anytime
Thomas Gleixner [EMAIL PROTECTED] writes:
On Fri, 19 Oct 2007, Jeff Garzik wrote:
WARNING NOT FOR MERGE WARNING NOT FOR MERGE WARNING NOT FOR MERGE
This posting is just to demonstrate something that I have been keeping
alive in the background. I have no urge to push it upstream anytime
Eric W. Biederman wrote:
Yes. keeping this alive is good.
The practical question is how do we make this change without breaking
the drivers that use their irq argument.
This is why I'm taking it slow, and not rushing to get this upstream :)
I am finding a ton of bugs in each
22 matches
Mail list logo