2.2.19 Documentation/Changes says pcmcia-cs 3.0.14. I am using 3.1.21
and it breaks if you compile the kernel with scsi support then try to
compile pcmcia. clients/apa1480_stub.c in 3.1.21 has
#include <../drivers/scsi/aic7xxx.h>
but in 2.2.19 that file is drivers/scsi/aic7xxx/aic7xxx.h. You need at
least pcmcia-cs 3.1.25 for kernel 2.2.19 with scsi support.
In the kernel and associated utilities I want to remove lines like
#include <../drivers/scsi/aic7xxx.h>
and replace them with
#include "aic7xxx.h"
with the Makefile specifying -I $(TOPDIR)/drivers/scsi (2.2.18) or -I
$(TOPDIR)/drivers/scsi/aic7xxx (2.2.19). Hard coding long path names
for #include is bad, especially when they contain '..'. It stops
kernel developers moving code around and makes it difficult to do some
of the things I plan for the 2.5 Makefile rewrite. David, how easy
would it be to change pcmcia to this style of include?
On Mon, Mar 26, 2001 at 05:14:13PM +1000, Keith Owens wrote:
> 2.2.19 Documentation/Changes says pcmcia-cs 3.0.14. I am using 3.1.21
> and it breaks if you compile the kernel with scsi support then try to
> compile pcmcia. clients/apa1480_stub.c in 3.1.21 has
> #include <../drivers/scsi/aic7xxx.h>
> but in 2.2.19 that file is drivers/scsi/aic7xxx/aic7xxx.h. You need at
> least pcmcia-cs 3.1.25 for kernel 2.2.19 with scsi support.
Correct. It is not just the header file that is at issue, though; the
whole build procedure for the aic7xxx driver changed.
> In the kernel and associated utilities I want to remove lines like
> #include <../drivers/scsi/aic7xxx.h>
> and replace them with
> #include "aic7xxx.h"
> with the Makefile specifying -I $(TOPDIR)/drivers/scsi (2.2.18) or -I
> $(TOPDIR)/drivers/scsi/aic7xxx (2.2.19). Hard coding long path names
> for #include is bad, especially when they contain '..'. It stops
> kernel developers moving code around and makes it difficult to do some
> of the things I plan for the 2.5 Makefile rewrite. David, how easy
> would it be to change pcmcia to this style of include?
It would not be too hard to do what you suggest, but would make for
very long CPPFLAGS. Which is inconvenient if you like to actually see
what's going on when you do a build. I think more of the include
files at issue should probably be in the kernel include tree, and not
hidden in the driver tree. That would make the issue moot.
What are the things you're planning that will cause trouble? I would
also think it would be less of an issue with 2.5 if there is some hope
that in-kernel PCMCIA is going to be the standard.
-- Dave
On Mon, 26 Mar 2001 08:48:09 -0800,
David Hinds <[email protected]> wrote:
>On Mon, Mar 26, 2001 at 05:14:13PM +1000, Keith Owens wrote:
>What are the things you're planning that will cause trouble?
Support for building third party drivers and patch sets as separate
source trees. Base kernel in in one source tree, external patch or
driver set is in another source tree, kbuild reads from multiple source
trees and writes to a separate object directory. The multiple source
trees break the assumption that all source is in one tree, lines like
#include <../drivers/scsi/aic7xxx.h>
do not work with multiple sources.
You are right about the long compile lines though, example with three
source trees, reflowed for readability.
/usr/bin/kgcc -I /build/kaos/2.4.1-object-kdb/arch/i386/kernel/
-I /build/kaos/kdb/arch/i386/kernel/
-I /build/kaos/common/arch/i386/kernel/
-I /build/kaos/2.4.1-makefile-2.5/arch/i386/kernel/ -I-
-D__ASSEMBLY__ -D__KERNEL__ -I include -I .tmp_include/src_002
-I .tmp_include/src_001 -I .tmp_include/src_000 -traditional -c
-o arch/i386/kernel/trampoline.o
/build/kaos/2.4.1-makefile-2.5/arch/i386/kernel/trampoline.S