John, Linking is sufficient. Inlining is sufficient but not necessary.
If you need clarification we can talk to the FSF. --brian On Wed, 06 Aug 2003, John A. Boyd Jr. wrote: > 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 -- Brian F. G. Bidulock � The reasonable man adapts himself to the � [EMAIL PROTECTED] � world; the unreasonable one persists in � http://www.openss7.org/ � trying to adapt the world to himself. � � Therefore all progress depends on the � � unreasonable man. -- George Bernard Shaw � _______________________________________________ Linux-streams mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
