[PATCH] IRQ: ease out-of-tree migration to new irq_handler prototype

[PATCH] IRQ: ease out-of-tree migration to new irq_handler prototype

[William D Waddington]

From: william.waddington@beezmo.com

Ease out-of-tree driver migration to new irq_handler prototype.
Define empty 3rd argument macro for use in multi kernel version
out-of-tree drivers going forward.  Backportable drives can do:

(in a header)
#ifndef __PT_REGS
# define __PT_REGS , struct pt_regs *regs
#endif

(in code body)
static irqreturn_t irq_handler(int irq, void *dev_id __PT_REGS)

Signed-off-by: Bill Waddington <william.waddington@beezmo.com>

---

Has this suggestion by Ingo Molnar been implemented?  May I
submit it?  Is this how it's done?

--- 2.6.19-rc3/include/linux/interrupt.h.ORIG	2006-11-04 
09:15:16.000000000 -0800
+++ 2.6.19-rc3/include/linux/interrupt.h	2006-11-04 09:23:18.000000000 -0800
@@ -66,6 +66,14 @@

  typedef irqreturn_t (*irq_handler_t)(int, void *);

+/*
+ * Irq handler migration helper - empty 3rd argument
+ * #define __PT_REGS , struct pt_regs *regs
+ * for older kernel versions
+ */
+
+#define __PT_REGS
+
  struct irqaction {
  	irq_handler_t handler;
  	unsigned long flags;


Bill
-- 
--------------------------------------------
William D Waddington
Bainbridge Island, WA, USA
william.waddington@beezmo.com
--------------------------------------------
"Even bugs...are unexpected signposts on
the long road of creativity..." - Ken Burtch

Re: [PATCH] IRQ: ease out-of-tree migration to new irq_handler prototype

[Alexey Dobriyan]

On Sat, Nov 04, 2006 at 10:29:37AM -0800, William D Waddington wrote:
> Ease out-of-tree driver migration to new irq_handler prototype.
> Define empty 3rd argument macro for use in multi kernel version
> out-of-tree drivers going forward.  Backportable drives can do:
>
> (in a header)
> #ifndef __PT_REGS
> # define __PT_REGS , struct pt_regs *regs
> #endif

Backportable drivers should check kernel version themselves and define
__PT_REGS themselves.

> (in code body)
> static irqreturn_t irq_handler(int irq, void *dev_id __PT_REGS)

> +/*
> + * Irq handler migration helper - empty 3rd argument
> + * #define __PT_REGS , struct pt_regs *regs
> + * for older kernel versions
> + */
> +
> +#define __PT_REGS

Re: [PATCH] IRQ: ease out-of-tree migration to new irq_handler prototype

[William D Waddington]

Alexey Dobriyan wrote:
> On Sat, Nov 04, 2006 at 10:29:37AM -0800, William D Waddington wrote:
> 
>>Ease out-of-tree driver migration to new irq_handler prototype.
>>Define empty 3rd argument macro for use in multi kernel version
>>out-of-tree drivers going forward.  Backportable drives can do:
>>
>>(in a header)
>>#ifndef __PT_REGS
>># define __PT_REGS , struct pt_regs *regs
>>#endif
> 
> 
> Backportable drivers should check kernel version themselves and define
> __PT_REGS themselves.

I think I provided too much information :(  It would be sufficiently
helpful to just #define __PT_REGS <nothing> in  interrupt.h to make
things easier for low-life out-of-tree maintainers.  There isn't any
need to actualy detect version.  Just detect __PT_REGS already defined.

The "in a header" above referred to the driver's header - #ifdefs in
executable code really looks nasty IMHO.

The "#define __PT_REGS , ..." comment below was intended to be a
"helpful" note to driver writers.  Like I said, TMI.

>>(in code body)
>>static irqreturn_t irq_handler(int irq, void *dev_id __PT_REGS)
> 
> 
>>+/*
>>+ * Irq handler migration helper - empty 3rd argument
>>+ * #define __PT_REGS , struct pt_regs *regs
>>+ * for older kernel versions
>>+ */
>>+
>>+#define __PT_REGS

How should I tidy this up - if it is acceptable at all?  I'm a
total noob struggling with a 1-line patch.

Bill
-- 
--------------------------------------------
William D Waddington
Bainbridge Island, WA, USA
william.waddington@beezmo.com
--------------------------------------------
"Even bugs...are unexpected signposts on
the long road of creativity..." - Ken Burtch

Re: [PATCH] IRQ: ease out-of-tree migration to new irq_handler prototype

[Alexey Dobriyan]

On Sat, Nov 04, 2006 at 12:06:53PM -0800, William D Waddington wrote:
> Alexey Dobriyan wrote:
> >On Sat, Nov 04, 2006 at 10:29:37AM -0800, William D Waddington wrote:
> >
> >>Ease out-of-tree driver migration to new irq_handler prototype.
> >>Define empty 3rd argument macro for use in multi kernel version
> >>out-of-tree drivers going forward.  Backportable drives can do:
> >>
> >>(in a header)
> >>#ifndef __PT_REGS
> >># define __PT_REGS , struct pt_regs *regs
> >>#endif
> >
> >
> >Backportable drivers should check kernel version themselves and define
> >__PT_REGS themselves.
>
> I think I provided too much information :(  It would be sufficiently
> helpful to just #define __PT_REGS <nothing> in  interrupt.h to make
> things easier for low-life out-of-tree maintainers.  There isn't any
> need to actualy detect version.  Just detect __PT_REGS already defined.

Out-of-tree maintainer will have to change his code ANYWAY. And while he
is doing that, he can spend 10 seconds to add 5-line version check.

More, if you've followed pt_regs removal patches, you'd noticed that
some of them were not trivial. In this case version check is least of
his worries.

> The "in a header" above referred to the driver's header - #ifdefs in
> executable code really looks nasty IMHO.
>
> The "#define __PT_REGS , ..." comment below was intended to be a
> "helpful" note to driver writers.  Like I said, TMI.
>
> >>(in code body)
> >>static irqreturn_t irq_handler(int irq, void *dev_id __PT_REGS)
> >
> >
> >>+/*
> >>+ * Irq handler migration helper - empty 3rd argument
> >>+ * #define __PT_REGS , struct pt_regs *regs
> >>+ * for older kernel versions
> >>+ */
> >>+
> >>+#define __PT_REGS
>
> How should I tidy this up - if it is acceptable at all?

No, this is not acceptable.

Re: [PATCH] IRQ: ease out-of-tree migration to new irq_handler prototype

[William D Waddington]

Alexey Dobriyan wrote:
> On Sat, Nov 04, 2006 at 12:06:53PM -0800, William D Waddington wrote:
> 
>>Alexey Dobriyan wrote:
>>
>>>On Sat, Nov 04, 2006 at 10:29:37AM -0800, William D Waddington wrote:
>>>
>>>
>>>>Ease out-of-tree driver migration to new irq_handler prototype.
>>>>Define empty 3rd argument macro for use in multi kernel version
>>>>out-of-tree drivers going forward.  Backportable drives can do:
>>>>
>>>>(in a header)
>>>>#ifndef __PT_REGS
>>>># define __PT_REGS , struct pt_regs *regs
>>>>#endif
>>>
>>>
>>>Backportable drivers should check kernel version themselves and define
>>>__PT_REGS themselves.
>>
>>I think I provided too much information :(  It would be sufficiently
>>helpful to just #define __PT_REGS <nothing> in  interrupt.h to make
>>things easier for low-life out-of-tree maintainers.  There isn't any
>>need to actualy detect version.  Just detect __PT_REGS already defined.
> 
> 
> Out-of-tree maintainer will have to change his code ANYWAY. And while he
> is doing that, he can spend 10 seconds to add 5-line version check.

I'm a little out of my depth here (obviously) but why is it "better" to
require a version check rather than the kernel simply flagging the
function change?  Rather like HAVE_COMPAT_IOCTL.

With the proposed 1-line kernel patch my drivers build against kernels
back to 2.6.9 (the earliest I have around here) without any version
checking.

> More, if you've followed pt_regs removal patches, you'd noticed that
> some of them were not trivial. In this case version check is least of
> his worries.

Ah. I don't use the *regs arg.  The one line patch just keeps the
compiler happy. And provides a "tidy" way to detect the interface
change if necessary.

>>The "in a header" above referred to the driver's header - #ifdefs in
>>executable code really looks nasty IMHO.
>>
>>The "#define __PT_REGS , ..." comment below was intended to be a
>>"helpful" note to driver writers.  Like I said, TMI.
>>
>>
>>>>(in code body)
>>>>static irqreturn_t irq_handler(int irq, void *dev_id __PT_REGS)
>>>
>>>
>>>>+/*
>>>>+ * Irq handler migration helper - empty 3rd argument
>>>>+ * #define __PT_REGS , struct pt_regs *regs
>>>>+ * for older kernel versions
>>>>+ */
>>>>+
>>>>+#define __PT_REGS
>>
>>How should I tidy this up - if it is acceptable at all?
> 
> 
> No, this is not acceptable.

Oh well.

Thanks for your time,
Bill
-- 
--------------------------------------------
William D Waddington
Bainbridge Island, WA, USA
william.waddington@beezmo.com
--------------------------------------------
"Even bugs...are unexpected signposts on
the long road of creativity..." - Ken Burtch