Messages in this thread |  | | | From | Alessandro Amici <> | | Subject | Re: 2.5.37+ i386 arch split broke external module builds | | Date | Thu, 3 Oct 2002 01:49:37 +0200 |
| |
On Thursday 03 October 2002 00:09, James Bottomley wrote: > alexamici@tiscali.it said: > > comments are welcome, > > -#include "irq_vectors.h" > +#ifdef CONFIG_VISWS > +#include <asm/mach-visws/irq_vectors.h> > +#else > +#include <asm/mach-generic/irq_vectors.h> > +#endif > > I'm afraid the whole purpose of the code was to get away from this type of > #ifdef problem. If you do this, every new mach-type added to i386 has to > modify a bunch of kernel headers.
as i said, that was just a rough example, it is possible to do it in a much cleaner way. if we can agree on this being important enough i can prepare a nicer patch myself.
> dwmw2@infradead.org said: > > make -C /lib/modules/`uname -r`/build SUBDIRS=`pwd` modules > > This looks like a clean solution to me, since most kernel packages install > this module build directory.
i do agree with you and dwmw2. that one is The Right Way.
my problem is: current distributions (i know debian for sure, and suse from second hand experiance) are not prepared. if 2.6-3.0 will be released as it is _now_ and if distribution don't change policy, we will have no other choice than ask the users to compile and run a castom kernel, in order to use our driver. which means: cutting our future user base to a third (i'm optimistic :).
in this particular case i think a clean-enough workaround can be found, so i'd like to see it going in. if people agree on the general principle that external modules are better off using the kernel build system, thats fine with me. but then we need a clear statement on _what exactly_ is required for external module building, and distributions need to start follwing such an advise.
alessandro
- 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/
|  |