From: William D Waddington <william.waddington@beezmo.com>
To: Jesper Juhl <jesper.juhl@gmail.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [RFCLUE3] flagging kernel interface changes
Date: Sun, 21 Jan 2007 11:15:45 -0800 [thread overview]
Message-ID: <45B3BBE1.9090305@beezmo.com> (raw)
In-Reply-To: <9a8748490611151517r7779652ej910a33ca961ba025@mail.gmail.com>
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
prev parent reply other threads:[~2007-01-21 20:02 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-11-15 22:14 [RFCLUE3] flagging kernel interface changes William D Waddington
2006-11-15 22:25 ` Arjan van de Ven
2006-11-15 22:37 ` William D Waddington
2006-11-16 1:05 ` Bryan O'Sullivan
2006-11-15 23:17 ` Jesper Juhl
2007-01-21 19:15 ` 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=45B3BBE1.9090305@beezmo.com \
--to=william.waddington@beezmo.com \
--cc=jesper.juhl@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.