[RFCLUE3] flagging kernel interface changes

[RFCLUE3] flagging kernel interface changes

[William D Waddington]

I tried submitting a patch a while back:
"[PATCH] IRQ: ease out-of-tree migration to new irq_handler prototype"
to add #define __PT_REGS to include/linux/interrupt.h to flag the change
to the new interrupt handler prototype.  It wasn't well received :(

No big surprise.  The #define wasn't my idea and I hadn't submitted a
patch before.  I wanted to see how the patch procedure worked, and
hoped that the flag would be included so I could mod my drivers and
move on...

What I'm curious about is why flagging kernel/driver interface changes
is considered a bad idea.  From my point of view as a low-life out-of-
tree driver maintainer,

#ifdef NEW_INTERFACE
#define <my new internals>
#endif

(w/maybe an #else...)

is cleaner and safer than trying to track specific kernel versions in
a multi-kernel-version driver.  It seems that in some cases, the new
interface has been, like HAVE_COMPAT_IOCTL for instance.

I don't want to start an argument about	"stable_api_nonsense" or the
wisdom of out-of-tree drivers.  Just curious about the - why - and
whether it is indifference or antagonism toward drivers outside the
fold. Or ???

Apologies for the long post, and 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

Re: [RFCLUE3] flagging kernel interface changes

[Arjan van de Ven]

> I don't want to start an argument about	"stable_api_nonsense" or the
> wisdom of out-of-tree drivers.  Just curious about the - why - and
> whether it is indifference or antagonism toward drivers outside the
> fold. Or ???

Hi,

in general the best approach has been to make the driver support the NEW
interface, and then do some compat thing to fake the old one. The other
way around is going to be MUCH more painful long term.
So as general rule: always follow the latest API, and use a compat.h
hack for older kernels inside your driver, but keep the normal code
clean. It's not always easy, but keeping old API and faking it to the
new one is only going to be really really painful; things will deviate
more and more over time and at some point you'll have to jump anyway.

In addition quite a few api changes are done in a way that make this
less painful than the other way around..



however in general really there is pain to be out-of-tree; and to some degree that's an incentive to merge back :)

> - 
> if you want to mail me at work (you don't), use arjan (at) linux.intel.com
> Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org

Re: [RFCLUE3] flagging kernel interface changes

[William D Waddington]

Arjan van de Ven wrote:
>> I don't want to start an argument about	"stable_api_nonsense" or 
>> the wisdom of out-of-tree drivers.  Just curious about the - why - 
>> and whether it is indifference or antagonism toward drivers outside
>>  the fold. Or ???
> 
> 
> Hi,
> 
> in general the best approach has been to make the driver support the 
> NEW interface, and then do some compat thing to fake the old one. The
>  other way around is going to be MUCH more painful long term. So as 
> general rule: always follow the latest API, and use a compat.h hack 
> for older kernels inside your driver, but keep the normal code clean.
>  It's not always easy, but keeping old API and faking it to the new 
> one is only going to be really really painful; things will deviate 
> more and more over time and at some point you'll have to jump anyway.

Good point.  I actually try to do it that way.  Should have said

#ifndef NEW_INTERFACE
...

> In addition quite a few api changes are done in a way that make this
>  less painful than the other way around..

The other part of the question is why this irq_handler prototype change
in 2.6.19 isn't flagged to make things a little easier.

> however in general really there is pain to be out-of-tree; and to
> some degree that's an incentive to merge back  :)

No argument, but I don't have the stamina to try to get my 10+ year
old code out of the public domain and into the main line :)

Many thanks for your reply,
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: [RFCLUE3] flagging kernel interface changes

[Bryan O'Sullivan]

William D Waddington wrote:

> The other part of the question is why this irq_handler prototype change
> in 2.6.19 isn't flagged to make things a little easier.

For in-tree drivers, it broke the compilation of any drivers that relied 
upon it, and they were then fixed, and most of the fixing occurred 
before the changes made it into any widely used tree.  That 
break-it-and-fix-it approach is typically seen as flagging enough.  If 
your driver isn't in-tree, it's invisible to kernel maintainers.

For out-of-tree drivers, your best bet is to follow Jonathan Corbet's 
notes on LWN.  He's pretty good about describing impending widespread 
breakage before it hits the main tree.

	<b

Re: [RFCLUE3] flagging kernel interface changes

[Jesper Juhl]

On 15/11/06, William D Waddington <william.waddington@beezmo.com> wrote:
> I tried submitting a patch a while back:
> "[PATCH] IRQ: ease out-of-tree migration to new irq_handler prototype"
> to add #define __PT_REGS to include/linux/interrupt.h to flag the change
> to the new interrupt handler prototype.  It wasn't well received :(
>
> No big surprise.  The #define wasn't my idea and I hadn't submitted a
> patch before.  I wanted to see how the patch procedure worked, and
> hoped that the flag would be included so I could mod my drivers and
> move on...
>
> What I'm curious about is why flagging kernel/driver interface changes
> is considered a bad idea.  From my point of view as a low-life out-of-
> tree driver maintainer,
>
> #ifdef NEW_INTERFACE
> #define <my new internals>
> #endif
>
> (w/maybe an #else...)
>
> is cleaner and safer than trying to track specific kernel versions in
> a multi-kernel-version driver.  It seems that in some cases, the new
> interface has been, like HAVE_COMPAT_IOCTL for instance.
>
> I don't want to start an argument about "stable_api_nonsense" or the
> wisdom of out-of-tree drivers.  Just curious about the - why - and
> whether it is indifference or antagonism toward drivers outside the
> fold. Or ???
>

I would say that one reason is that cluttering up the kernel with
#ifdef's is ugly and annoying to maintain long-term. Especially when
it's expected that anyone who changes in-kernel interfaces also fix up
any user(s) of those interfaces, so the #ifdef's are pointless
(ignoring out-of-tree code that is).


-- 
Jesper Juhl <jesper.juhl@gmail.com>
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please      http://www.expita.com/nomime.html

Re: [RFCLUE3] flagging kernel interface changes

[William D Waddington]

Jesper Juhl wrote:
> On 15/11/06, William D Waddington <william.waddington@beezmo.com> wrote:
> 
>> I tried submitting a patch a while back:
>> "[PATCH] IRQ: ease out-of-tree migration to new irq_handler prototype"
>> to add #define __PT_REGS to include/linux/interrupt.h to flag the change
>> to the new interrupt handler prototype.  It wasn't well received :(
>>
>> No big surprise.  The #define wasn't my idea and I hadn't submitted a
>> patch before.  I wanted to see how the patch procedure worked, and
>> hoped that the flag would be included so I could mod my drivers and
>> move on...
>>
>> What I'm curious about is why flagging kernel/driver interface changes
>> is considered a bad idea.  From my point of view as a low-life out-of-
>> tree driver maintainer,
>>
>> #ifdef NEW_INTERFACE
>> #define <my new internals>
>> #endif
>>
>> (w/maybe an #else...)
>>
>> is cleaner and safer than trying to track specific kernel versions in
>> a multi-kernel-version driver.  It seems that in some cases, the new
>> interface has been, like HAVE_COMPAT_IOCTL for instance.
>>
>> I don't want to start an argument about "stable_api_nonsense" or the
>> wisdom of out-of-tree drivers.  Just curious about the - why - and
>> whether it is indifference or antagonism toward drivers outside the
>> fold. Or ???
>>
> 
> I would say that one reason is that cluttering up the kernel with
> #ifdef's is ugly and annoying to maintain long-term. Especially when
> it's expected that anyone who changes in-kernel interfaces also fix up
> any user(s) of those interfaces, so the #ifdef's are pointless
> (ignoring out-of-tree code that is).

Ah, but out-of-tree code is what I'm stuck w/maintaining.  I wouldn't
want to infest in-tree drivers w/#ifdef's either, but they are a fact
of life in my world.  And, lately, _really_ ugly version tests.

If I had _my_ way, there would be a kernel_interface_change.h file that
had an #define'd entry for _every_ kernel interface change within a
major release series:

/*
  * include/linux/interrupt.h interface change x.y.z
  * interrupt handler now takes 2 args
  */
#define INTERRUPT_H_CHANGE_X.Y.Z "interrupt handler now takes 2 args"

or something.

I understand that many (most?) kernel maintainers would prefer that
all drivers be brought in-tree, and aren't particularly concerned
when interface changes affect out-of-tree drivers.

Respectfully, I suggest that world domination isn't quite the same
thing as world dictatorship, and maybe the road to the former would
be helped by a little less of the latter :)

Rat-bastard out-of-tree maintainer takes refuge under desk....

Thanks,
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