Messages in this thread | | | Date | Wed, 15 Nov 2006 14:14:11 -0800 | From | William D Waddington <> | Subject | [RFCLUE3] flagging kernel interface changes |
| |
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 - 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/
| |