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
