[PATCH] Re: CardServices release does not match
Sat May 24 16:46:37 PDT 2003
On Sat, 24 May 2003, Slobodan Tomic wrote:
> What does 'dmesg' say? If it still says that CardServices release does
> not match, try quick hack: put 'PCMCIA_PATH=/path/to/your/local/pcmcia'
> at the beginning of driver/module/Makefile.
Actually, this won't work. It's my error. I only tested my previous
patch if PCMCIA_PATH is set on the command line. If it's set in the
Makefile, it needs to be exported.
The attached patch exports PCMCIA_PATH and also introduces some basic
checks to avoid common errors.
If PCMCIA_PATH is set to an invalid or missing directory, exit with an
error. If both CONFIG_PCMCIA and PCMCIA_PATH are set, it's an error too -
you don't need to specify PCMCIA_PATH if kernel PCMCIA support is present.
If neither CONFIG_PCMCIA nor PCMCIA_PATH are defined, it's a warning.
Ideally, hostap_cs shouldn't be built and installed in this case, but
let's leave it for another patch.
There is no need to add "-I$(PCMCIA_PATH)/include" to INCLUDES in the
top-level Makefile. INCLUDES is only used to find KERNELRELEASE, which is
independent of pcmcia-cs. This still looks too complicated to me.
Cannot we use "sed" to get UTS_RELEASE from include/linux/version.h or
even directly from the kernel top-level Makefile?
Since depmod is run after every installed modules, make can fail because
of unresolved symbols if the already installed modules that are about to
be replaced. I see two ways to avoid this problem. One is to create
private targets like _install_pcard without depmod and make sure that
public targets only call depmod at the end. Another approach is to
introduce "uninstall" target that would remove old modules before depmod
is run the first time. The patch implements the second approach.
We may need to run "make uninstall" for 2.5 kernels as well if hostap_cs
becomes optional (to remove old hostap_cs if PCMCIA has been disabled
since it was compiled), but it's not in this patch.
More information about the Hostap