Hello Dave:
Thanks for the response and further direction.
In dki.c, there is an original declaration of "struct tlist" and
the alternate (conditional) declaration of the kmem_cache object:
"struct listimer". There are also the original functions: lis_untimeout(),
lis_terminate_dki(), lis_timeout_fcn() and the alternate instantiations
of the same functions when kmem_cache is being used.
In msg.c, there is the original declaration of:
volatile struct mdbblock *lis_mdbfreelist = NULL;
and the conditional declaration of the kmem_cache object:
static kmem_cache_t *lis_msgb_cachep = NULL;
This is a good example of how I do not want it to be implemented. What you need are some interfacing routines with names such as lis_mblk_init(), lis_mblk_alloc(), lis_mblk_free(), or whatever, that are defined in lismem.c and called from msg.c. You can use Linux kernel constructs to your heart's content in lismem.c. But only call the abstract routines from msg.c.
Then put the same routines into head/user/port.c with conventional memory allocation for use in the user-mode build of LiS. Be sure to do the user-mode build and run strtst to ensure that you have all those bases covered.
Follow this method for other kernel-isms that you need in order to achieve optimization. In effect you are turning these kernel mechanisms, or LiS mechanisms that are going to use the kernel mechanisms, into "objects" with a function-calling interface.
If someone then ports LiS to some other OS then they will have to duplicate the functions in lismem.c using whatever that OS presents as the underlying mechanism.
This keeps the kernel-isms in a small number of files.
> 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. ---> ---> I'm not altering the spin lock and semaphore structures one iota. ---> ---> With respect to the __FILE__ and __LINE__ (and sometime __FUNCTION__ ) ---> parameters matter. Are you saying that the following type of construct ---> (taken from include/sys/lislocks.h) is not desirable/acceptable? If ---> so, I have to "back out" some changes before I can "submit" the code. ---> ---> #if defined(CONFIG_DEV) ---> #define lis_splstr() lis_splstr_fcn(__FILE__,__LINE__) ---> #define lis_splx(x) lis_splx_fcn(x,__FILE__,__LINE__) ---> #define lis_spl0(x) lis_spl0_fcn(__FILE__,__LINE__) ---> #else ---> #define lis_splstr() lis_splstr_fcn() ---> #define lis_splx(x) lis_splx_fcn(x) ---> #define lis_spl0(x) lis_spl0_fcn() ---> #endif --->
Another good example of how not to do it. Because you change the calling sequence of the function based upon a compile time variable, every STREAMS driver would have to be sensitive to that same variable in order to call the function properly. This violates a design criterion for LiS that precompiled binary STREAMS drivers will operate with as many different versions of LiS as is practical without recompilation.
The kernel guys have no such criterion and it drives us all nuts. Every time a new kernel version comes out they change something in the driver/kernel interface, even down to gratuitous changes to the names of structure fields. I want LiS to have the opposite property and maintain the driver interface as constant as is feasible.
Solaris, by the way, has such a constant DKI that we have not had to change driver code since 2.6. UnixWare went to phenomenal lengths including linker gymnastics to preserve old DKIs.
So, bottom line, I think you need to keep the file,line parameters with the routines and then have the routines just not do anything with them. This holds the function prototype constant irrespective of LiS installation options.
-- Dave
_______________________________________________ Linux-streams mailing list [EMAIL PROTECTED] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
