[lkml]   [2002]   [Oct]   [2]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: 2.5.37+ i386 arch split broke external module builds
On Thursday 03 October 2002 00:09, James Bottomley wrote:
> 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.

> 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


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:29    [W:0.084 / U:1.252 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site