Some components don't have 'uninstall' targets although the top-level
Makefile references them. Some others don't remove the proper file.
Signed-off-by: Steven J. Magnani <steve@digidescorp.com>
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@5290 d57e44dd-8a1f-0410-8b47-8ef2f437770f
Not all SCST components handle DESTDIR properly, or at all.
In particular:
* INSTALL_MOD_PATH should account for DESTDIR when 'make modules_install'
is invoked, so the kernel make infrastructure deploys the modules
and runs depmod against the proper directory tree.
* depmods must include a '-b' option to reference the proper directory tree.
* Drop special ISCSI_DESTDIR.
Signed-off-by: Steven J. Magnani <steve@digidescorp.com>
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@5289 d57e44dd-8a1f-0410-8b47-8ef2f437770f
When deriving the kernel version (KVER) from KDIR, the file
$(KDIR)/include/config/kernel.release should be preferred over
'make kernelversion'.
For example, the Ubuntu 3.2.0-23-generic kernel has a kernel.release
file containing '3.2.0-23-generic', but 'make kernelversion' returns
3.2.14. Since the modules are stored under /lib/modules/3.2.0-23-generic,
the value in kernel.release is the correct one to use.
Also:
- Evaluate KVER only once
- All depmod commands must include KVER
Signed-off-by: Steven J. Magnani <steve@digidescorp.com>
[bvanassche: Split long lines / removed trailing whitespace]
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@5286 d57e44dd-8a1f-0410-8b47-8ef2f437770f
Running 'make modules_install' already triggers invocation of depmod,
hence leave it out from those Makefiles that use 'make modules_install'.
Signed-off-by: Steven J. Magnani <steve@digidescorp.com>
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@5283 d57e44dd-8a1f-0410-8b47-8ef2f437770f
BUILD_2X_MODULE=y should be passed to make. New module named
qla2xxx_scst. Obviously, to have it working, the original qla2xxx should
be either blacklisted, or removed from the target system.
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@3910 d57e44dd-8a1f-0410-8b47-8ef2f437770f
- Moved qla2x00t patch generation code from qla2x00t/Makefile to
qla2x00t/extract-qla2xxx-orig and qla2x00t/generate-in-tree-patches.
Restored qla2x00t/Makefile to r1104.
- scripts/run-regression-tests now passes the full kernel version (including
patch level) to scripts/generate-kernel-patch.
- scripts/generate-kernel-patch can now generate patches for the files
in drivers/scsi/qla2xxx for any kernel version instead of only 2.6.26.8.
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@1198 d57e44dd-8a1f-0410-8b47-8ef2f437770f
follows:
- Building the QLogic target driver is possible by following the instructions
in qla2x00t/qla2x00-target/README.
- Some but not all of the qla2x00-target code is included in the output of
scripts/generate-kernel-patch. This is unfortunate because it is the output
of this script that is posted to the LKML each time SCST is submitted for
review.
- Most of the qla2x00-target code is checked during the nightly build by
checkpatch. None of the qla2x00-target code is checked during the nightly
build by sparse.
The patch below makes sure that all of the qla2x00-target code is included in
the generate-kernel-patch output and also that all of the qla2x00-target code
is checked during the nightly build by both checkpatch and sparse. This has
been realized by including the diff of the linux-2.6.26.8/drivers/scsi/qla2xxx
source files and the source files in qla2x00t/*[ch] as individual patches under
qla2x00t/in-tree-patches. These patches are generated from downloaded
linux-2.6.26.8 sources and the sources in the SCST SVN repository.
The next step is to fix the checkpatch and sparse warnings triggered by the
qla2x00-target code and to port the latest qla2xxx patches to the SCST
qla2x00t implementation.
Signed-off-by: Bart Van Assche <bart.vanassche@gmail.com>
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@1189 d57e44dd-8a1f-0410-8b47-8ef2f437770f
While writing DKMS support for the SCST and iSCST-SCST kernel modules, I ran
into a (common) problem with regard to out-of-tree build detection. A common
method to detect out-of-tree building is by using the KERNELRELEASE variable.
The usage of this variable poses a problem when using DKMS. DKMS itself uses
the KERNELRELEASE variable to specify the kernel for which the driver to
build. A suggested alternative would to use the PATCHLEVEL variable as part
of the detection mechanism instead. I attached a patch reflecting this
suggested change.
git-svn-id: http://svn.code.sf.net/p/scst/svn/trunk@720 d57e44dd-8a1f-0410-8b47-8ef2f437770f
Bart Van Assche
Vladislav Bolkhovitin