Messages in this thread | | | Date | Thu, 16 Nov 2006 00:17:52 +0100 | From | "Jesper Juhl" <> | Subject | Re: [RFCLUE3] flagging kernel interface changes |
| |
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |