Re: [Linux-streams] Re: Performance enhanced LiS

[Francois-Xavier KOWALSKI]

David Grothe wrote: [...] 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. This protection has been explicitly declared as non-applicable by L. Torvalds: "Using function pointers won't save you from the GPL". Exact quote below. Direct inlining is also good when there is a deadlock on a system using crash-dump feature: the crash-dump backtrace of the offending process(es) contains the exact location of the lock, rather than the lis wrapper code. I strongly vote _for_ inlining of functions. Best regards. -- FiX From: Linus Torvalds <[EMAIL PROTECTED]> To: Christoph Hellwig <[EMAIL PROTECTED]> Subject: Re: [PATCH] make LSM register functions GPLonly exports Date: Thu, 17 Oct 2002 10:08:19 -0700 (PDT) Cc: Crispin Cowan <[EMAIL PROTECTED]>, Greg KH <[EMAIL PROTECTED]>, <[EMAIL PROTECTED]> Note that if this fight ends up being a major issue, I'm just going to remove LSM and let the security vendors do their own thing. So far - I have not seen a lot of actual usage of the hooks - seen a number of people who still worry that the hooks degrade performance in critical areas - the worry that people use it for non-GPL'd modules is apparently real, considering Crispin's reply. I will re-iterate my stance on the GPL and kernel modules: There is NOTHING in the kernel license that allows modules to be non-GPL'd. The _only_ thing that allows for non-GPL modules is copyright law, and in particular the "derived work" issue. A vendor who distributes non-GPL modules is _not_ protected by the module interface per se, and should feel very confident that they can show in a court of law that the code is not derived. The module interface has NEVER been documented or meant to be a GPL barrier. The COPYING clearly states that the system call layer is such a barrier, so if you do your work in user land you're not in any way beholden to the GPL. The module interfaces are not system calls: there are system calls used to _install_ them, but the actual interfaces are not. The original binary-only modules were for things that were pre-existing works of code, ie drivers and filesystems ported from other operating systems, which thus could clearly be argued to not be derived works, and the original limited export table also acted somewhat as a barrier to show a level of distance. In short, Crispin: I'm going to apply the patch, and if you as a copyright holder of that file disagree, I will simply remove all of he LSM code from the kernel. I think it's very clear that a LSM module is a derived work, and thus copyright law and the GPL are not in any way unclear about it. If people think they can avoid the GPL by using function pointers, they are WRONG. And they have always been wrong. Linus -- Francois-Xavier "FiX" KOWALSKI /_ __ Tel:+33 (0)4 76 14 63 27 OpenCall Business Unit -- OCBU / //_/ Telnet: 779-6327 Signalling Products / http://www.hp.com/go/opencall i n v e n t