[ofa-general] Re: [PATCH 2/2] IB/iser: add backport & kernel addons foropen-iscsiover iSER support for RHAS4 up3 and up4
Michael S. Tsirkin
mst at dev.mellanox.co.il
Wed May 30 05:54:56 PDT 2007
> >> The main
> >> change is a new dir called "kernel_addons_patches". It contains patches
> >> for kernel tree files in order to create the required addons from them.
> >>
> >
> > sorry, but I really don't think we can touch build scripts at this point.
> > Doing cp in build scripts is also a problem since it interferes with
> > development (there are 2 places to edit each file).
> > And adding kernel version dependency there is also really messy.
> >
> > Suggestion: why can't these patches be part of the regular backport directory?
> >
> > you copy stuff to include/src and then include it, but this just looks
> > like and unnecessary extra step. Can't we include the source file from
> > it original place directory, like this:
> > #include "../drivers/base/attribute_container.c"
> >
>
> I can use attribute_container.c from drivers/base. However, having some
> of the addons in drivers/base while most of the addons are in
> kernel_addons is confusing, isn't it?
No, because it's not an addon - this is actual upstream kernel code.
Addons is stuff that we *add* to kernel.
> It will also require ugly
> adjustments like:
>
> kernel_patches/backport/2.6.9_U3/iscsi_scsi_addons.patch:
>
> diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile
> index e212608..3bf2015 100644
> --- a/drivers/scsi/Makefile
> +++ b/drivers/scsi/Makefile
> @@ -1,2 +1,7 @@
> obj-$(CONFIG_SCSI_ISCSI_ATTRS) += scsi_transport_iscsi.o
> obj-$(CONFIG_ISCSI_TCP) += libiscsi.o iscsi_tcp.o
> +
> +CFLAGS_attribute_container.o =
> -I$(PWD)/kernel_addons/backport/2.6.9_U3/include/src/
> +
> +scsi_transport_iscsi-y := scsi_transport_iscsi_f.o scsi.o scsi_lib.o
> init.o klist.o attribute_container.o transport_class.o
> +libiscsi-y := libiscsi_f.o scsi_scan.o
>
> (because base.h is in kernel_addons/backport/2.6.9_U3/include/src)
This is one approach, and I think it's not too bad.
Alternative is to use the relative path for include directive:
#include "../drivers/base/attribute_container.c"
Wouldn't this work?
--
MST
More information about the general
mailing list