From: William D Waddington <william.waddington@beezmo.com>
To: Alexey Dobriyan <adobriyan@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] IRQ: ease out-of-tree migration to new irq_handler prototype
Date: Sun, 05 Nov 2006 06:56:23 -0800 [thread overview]
Message-ID: <454DFB97.1060703@beezmo.com> (raw)
In-Reply-To: <20061105020431.GA20243@martell.zuzino.mipt.ru>
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
prev parent reply other threads:[~2006-11-05 14:56 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-04 18:29 [PATCH] IRQ: ease out-of-tree migration to new irq_handler prototype William D Waddington
2006-11-04 19:03 ` Alexey Dobriyan
2006-11-04 20:06 ` William D Waddington
2006-11-05 2:04 ` Alexey Dobriyan
2006-11-05 14:56 ` William D Waddington [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=454DFB97.1060703@beezmo.com \
--to=william.waddington@beezmo.com \
--cc=adobriyan@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox