![]() | |||||||||||||
Messages in this thread |
On Wed, Jan 12, 2005 at 10:43:26PM +0100, Andi Kleen wrote: > > No, we do not do that in the kernel today, and I'm pretty sure we don't > > Actually we do. e.g. take a look at skbuff.h HAVE_* > There are other examples too. > > > want to start doing it (it would get _huge_ very quickly...) > > I disagree since the alternative is so ugly. But the main problem with this is, when do we start deleting the HAVE_ symbols? After a relativly short period of time, they become useless, as all kernels of the past year or two have that feature, and why even test for it? I agree, that for short term, vendor-patched kernels, it's nice to have something like that to try to build your out-of-the-tree module. But move to get that module into the tree, or provide your favorite vendor with the properly patched driver (hey, I can dream...) And is the alternative (using autoconf to build tiny modules testing for different features) that ugly? Yeah, I hate autoconf too, but I thought that work (kernel feature testing in autoconf) has already been done, right? > > Please don't apply this. Remember, out-of-the-tree modules are on their > > own. > > I don't know who made this "policy", but actively sabotating or denying > useful facilities to free out of tree modules doesn't seem to be a > very wise policy to me. I'm not trying to sabotage anything, I just don't want the maintaince of a zillion HAVE_ macros to slowly overrun us until we drown under the weight. All to support some looney, ill-informed vendor that can never get around to submitting their driver to mainline. And as for that "policy", it's been stated in public by Andrew and Linus and me (if I count for anything, doubtful...) a number of documented times. thanks, greg k-h - 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/ | ||||||||||||
| Last update: 2005-03-22 14:09 [from the cache] ©2003-2008 | |||||||||||||