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 -- 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
