First, if we're voting again, I agree with Dave over Linus' apparent disagreement, with all due respect to Linus, in this regard: avoiding inlining is not a sufficient condition for avoiding GPL, but it is a necessary one in technical terms. Code that is inlined is code that is included in the work in question, and thus certainly makes it derivative. (That's a legal opinion, though I'm not a lawyer, but one who has been involved with this very legal issue as a "party with standing.")
But on the subject of what would be sufficient, I want to ask you a question, Dave. From a legal perspective, was is a good idea to obsolete the system call interfaces? I suspect that having them there in usable form, even if not normally used, would support the legal case that the appropriate barrier has been observed, as a matter of due diligence.
And following from that thought, it occurs to me that the Linux kernel does not fully support a pure syscall relationship with the current LiS, notably in the case of FATTACH/FDETACH, which are syscalls in most Unix kernels but are not allocated in the Linux kernel. I don't really want to go there myself, but it would seem to me that providing a full syscall barrier would require that these be added to the kernel.
I think that if the question ever came up in court, one seeking to show LGPL but not GPL coverage would have to demonstrate due diligence towards meeting the explicit requirements of the LGPL as exclusive from the GPL. Thus, this effort must be made and documented if that is the desired end. If it then fails, it would probably satisfy a court that every reasonable attempt was made.
-John
Brian F. G. Bidulock wrote:
Dave,
IANAL, but it appears that you are confusing compiler linkage (inline vs. call) with licensing. LiS cannot turn pure GPL code into LGPL code by placing a wrapper function around it. Much of the kernel code is LinusGPL which is effectively the same as LGPL, but that which is pure GPL cannot be wrappered away to LGPL by LiS.
LiS, loading as a module, can do all the things that any other Linux kernel module can do, including being proprietary. LiS cannot extend anything to a kernel module that is not already enjoyed by that kernel module in the first place. Therefore, if LiS under LGPL is permitted to inline a function call (or call it at all) then any other kernel module in the world is also allowed to do the same.
Did you think that LiS could somehow extend the rights of a kernel module? (It cannot.)
Did you thinkg that LiS could somehow protect another kernel module from copyright violation? (It cannot.)
So LiS can be an evironmental buffer, yes, but not a licensing buffer. As an environmental buffer there is no reason to avoid inlining functions.
--brian
On Tue, 05 Aug 2003, Dave Grothe wrote:
I would prefer that these things be confined to defines in linux-mdep.h. You can put your conditionals there. Make the defines use either the optimized functions or the "debug" functions. Use the defines in all the places that you cited below. This keeps the ifdefs and kernel-isms in one place.
It is also OK to place kernel-isms in lislocks.c and lismem.c.
One important point. If you are conditionally turning such functions as lis_spin_lock() into direct inline uses of kernel functions (via defines) then you are creating a licensing ambiguity where there was none before. If only LiS calls kernel functions then only LiS is susceptible to the viral nature of the kernel's GNU license. Any separately loaded STREAMS driver that accesses the kernel only via LiS is safe since it does not use any kernel inlines.
If you, via your optimization patch, introduce direct kernel inlines into STREAMS driver code then you have extended the viral properties of the kernel's GNU license into STREAMS drivers themselves. This would violate a design principle for LiS. LiS must act as an environmental and licensing buffer between STREAMS drivers and the kernel.
In that regard I would really prefer to see the optimized locking functions (for example) continue to pass the file and line number information to functions in lislocks.c and then conditionally have those functions not use the information. The LiS spin lock and semaphore structures should be the same whether the optimized LiS is being used or not.
If you do this then a binary STREAMS driver is not itself sensitive to whether LiS has been installed as optimized or debug. It is unacceptable from an LiS design standpoint for STREAMS drivers to need recompilation because of different LiS installation options.
-- Dave
At 06:16 PM 8/4/2003 Monday, you wrote:
Hi Dave:
Thanks for the positive response regarding my offer. I look forward to working this matter with you and the LiS users.
What type of items do classify as Linux "Kernel-isms"? The reason I ask is because the kmem_cache enhancements have been made to:
head/dki.c kmem_cache used for struct lis_timer. There is conditional compiled alternate code for: to lis_timeout_fcn() and lis_untimeout().
head/head.c conditional compilation of declaration and initialization of lis_tlist_lock.
head/msg.c conditional compilation of declaration and initialization of kmem_cache for mdbblock-s depending on whether or not kmem cache is being used.
conditional compilation of alternate allochdr()
and freehdr() functions depending on whether
or not kmem cache is being used.
head/queue.c conditional compilation of alternate kmem cache
memory create/destroy and initialization for queue
and qband structures.
conditional compilation to use kmem_cache_alloc()/kmem_cache_free
or ALLOCF/ALLOCF_CACHE/FREE to allocate/free a qband or queue
structure depending on whether or not kmem cache is being used.
include/sys/dki.h conditional compilation of functions prototypes to
support kmem_cache option.
include/sys/LiS/msg.h conditional compilation of functions prototypes to
support kmem_cache option.
include/sys/LiS/queue.h conditional compilation of functions prototypes to
support kmem_cache option.
Thanks, Matt - Adax, Inc.
On Mon, 4 Aug 2003, David Grothe wrote:
Matt:
I would be happy to incorporate them. I do have one proviso: Please ensure that any Linux kernel-isms are confined to linux-mdep.[ch]. Kernel-isms in other files should be guarded by #ifdef LINUX, but these tend to disturb the readability of the code, so I prefer keeping the changes in linux-mdep.[ch].
Perhaps a few others would like to test the patches before we incorporate them into the released version of LiS.
Thanks for the effort. It sounds like you are taking a good approach.
-- Dave
At 02:13 PM 8/4/2003 Monday, Matthew Gierlach wrote:
Hello Dave:
I have concluded my 1st phase efforts to construct a performance enhanced LiS based on off the shelf LiS.
I'll provide the code to the LiS project for the benefit of all LiS users. Will you accept the submission and include it in the going forward releases?
I have source code for both LiS-2.16.11 and LiS-2.16.12. The performance gain is nearly 100% compared to the off the shelf LiS distribution. The changes include:
1) LiS can now be compiled for development or production use. The Configure script prompts the user for the attribute (development or production) of LiS they would like to build. A production built LiS achieves a large portion of the 100% performance improvement.
When compiled with the production attribute, LiS code path tracing and lock & semaphore use tracing is disabled.
Also, with the production attribute, LiS no longer obtains __FILE__ and __LINE__ function parameters from the LiS user and consequently, no longer carries __FILE__ and __LINE__ function parameters through to all the internal LiS functions. This reduces LiS execution time by eliminating the need for two 32-bit stack values for nearly every LiS function call.
2) LiS can now be compiled to use Linux kmem_cache for LiS queue and mblk structures. The Configure script prompts the user for this choice.
This is an enhancement that uses Linux kmem_cache storage for LiS queue and mblk structures instead of conventional kernel memory.
The enhancements have been tested with several Adax drivers running for many consecutive days over the past month.
I look forward to your response.
Matt Gierlach - Adax, Inc.
_______________________________________________ Linux-streams mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
_______________________________________________ Linux-streams mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
