[ewg] Re: [Scst-devel] [ofa-general] OFED 1.3 RC2 release is available
Bart Van Assche wrote: On Jan 28, 2008 12:47 PM, Vladislav Bolkhovitin [EMAIL PROTECTED] wrote: Bart Van Assche wrote: Apparently OFED 1.3 includes SRP target support ? Although I consider SRP target support as a very valuable contribution, it should not be included in the OFED distribution but in the SCST distribution. The reason is that the SRP target relies on SCST interfaces that can potentially change with each new SCST release. Consider e.g. the scsi_tgt.h header file, which defines the interface between SCST core and SCST mid-level modules. The version of this file included with git://git.openfabrics.org/~vu/ofed_1_3.git (0.9.6-pre3) is incompatible with the latest scsi_tgt.h file from the SCST project (0.9.6-rc1). This may cause kernel crashes for OFED 1.3 SRP target users who combine OFED 1.3 with the latest SCST version. No it won't crash, it will refuse to run. I've recently added in SCST protection against attempts running mixed SCST and target driver versions. BTW, there is a *!!* *!! !!* *!! BIG FAT WARNING ABOUT MIXED VERSIONS PROBLEM !!* *!! !!* *!!* Hello Vladislav, I did not test the above scenario -- what I wrote was the result of source reading. It is very good that interface versions are checked inside SCST before mid-level drivers are used. Even with interface version checking in place, my opinion is that the SRP target code should be included in the SCST project and not in the OFED project. Bart. Hi Bart, On srpt readme file, the prerequisite is install SCST BEFORE ofed-1.3 or like Vlad warning recompiling ofed if you install scst after install ofed. here is one of the reason srpt is part of ofed not scst: SCST is GPL ofed + srpt is GPL or BSD -vu ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [Scst-devel] [ofa-general] OFED 1.3 RC2 release is available
On Jan 28, 2008 12:47 PM, Vladislav Bolkhovitin [EMAIL PROTECTED] wrote: Bart Van Assche wrote: Apparently OFED 1.3 includes SRP target support ? Although I consider SRP target support as a very valuable contribution, it should not be included in the OFED distribution but in the SCST distribution. The reason is that the SRP target relies on SCST interfaces that can potentially change with each new SCST release. Consider e.g. the scsi_tgt.h header file, which defines the interface between SCST core and SCST mid-level modules. The version of this file included with git://git.openfabrics.org/~vu/ofed_1_3.git (0.9.6-pre3) is incompatible with the latest scsi_tgt.h file from the SCST project (0.9.6-rc1). This may cause kernel crashes for OFED 1.3 SRP target users who combine OFED 1.3 with the latest SCST version. No it won't crash, it will refuse to run. I've recently added in SCST protection against attempts running mixed SCST and target driver versions. BTW, there is a *!!* *!! !!* *!! BIG FAT WARNING ABOUT MIXED VERSIONS PROBLEM !!* *!! !!* *!!* Hello Vladislav, I did not test the above scenario -- what I wrote was the result of source reading. It is very good that interface versions are checked inside SCST before mid-level drivers are used. Even with interface version checking in place, my opinion is that the SRP target code should be included in the SCST project and not in the OFED project. Bart. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
[ewg] Re: [Scst-devel] [ofa-general] OFED 1.3 RC2 release is available
On Jan 28, 2008 1:23 PM, Vladislav Bolkhovitin [EMAIL PROTECTED] wrote: But that won't change anything. The problem will be simply inverted: there will be a possibility to run a SRPT driver compiled for a wrong OFED version. The SRP target driver indeed relies on several OFED kernel headers, but these kernel headers are included in the mainstream Linux kernel since some time. When I need OFED kernel modules, I use the modules included with the mainstream Linux kernel and not those included with the OFED distribution. With regard to distribution of kernel code that is newer than the most recent mainstream Linux kernel I prefer the model followed by the realtime community: do not distribute the whole source tree but publish an up-to-date patch every time a new kernel version is released. See also http://www.kernel.org/pub/linux/kernel/projects/rt/. Keeping such a patch up to date is more work but is a lot easier to review than having to compare source trees. Bart. ___ ewg mailing list ewg@lists.openfabrics.org http://lists.openfabrics.org/cgi-bin/mailman/listinfo/ewg
