Eugene,
Are you using Brian's LiS or some other version? Please note that my comments below are only relevant if you are not using Brian's version. If you are then whatever Brian says about his code goes since I've never seen it. --- "Brian F. G. Bidulock" <[EMAIL PROTECTED]> wrote: > EugeneLisStreams, > > On Wed, 31 Aug 2005, [EMAIL PROTECTED] wrote: > > > Brian, > > > > 1. > > Does it mean I now have to append _RP before my mod_open(), > mod_close() > > and other functions from my driver which I use to populate qinit > structure > > in the same manner as LiS 2.18 does it before connld_open? > > No, in fact you should not. What these _RP macros do is to insulate drivers and modules from kernels which are built with mregparm=3. What this means is that since LiS _should_ be the only thing calling kernel functions, it has to be built with the same mregparm settings as the kernel. LiS functions which you call from your driver are built with mregparm(0) so that all parameters are passed on the stack. This means in theory that you only need one binary of your driver to support kernels which use either mregparm=3 or mregparm=0, however you need to explicitly set -mregparm=0 when you build your driver. SuSE 32 bit kernels use the -mregparm=3 while Red Hat 32 bit kernels use -mregparm=0. 64 bit kernels have their own ABI so should not have any -mregparm settings in either LiS nor your driver. Also note that the easiest way to build your driver under 2.6 kernels is to use the kernel's module build system which takes care of all of the details of turning your .o into a .ko for inclusion into the system. Also note that you should not call any kernel functions directly. You should only call LiS exported functions which have this _RP coloring. This way you can just compile you driver/module with -mregparm=0 and not have to worry if the kernel uses -mregparm=0 or -mregparm=3. If you call a kernel function directly on a kernel which uses -mregparm=3, then it will crash since that called function's parameters will not be where the function expects them to be. > > Like if 2.18 does: > > > > static int _RP connld_open(queue_t *, dev_t*, int, int, cred_t > *); > > > > should I also do : > > > > int _RP mymod_open(...); > > ? > > > Dunno. I defeated the entire _RP thing in the autoconf build. The > autoconf build properly detects kernel build parameters. The _RP thing is there for the reason that I explained above, to insulate the user's driver from differences in the parameter passing conventions of the kernel. > > 2. > > > > LiS does a good job of finding CC compilation options based on > > info extracted from kernel and other sources. > > > > When I compile my module for LiS I apparently need to use exactly > > > the same CC options that LiS has already found and used. > > Actually, it does a poor job. For 2.18.1 build I rip kernel flags > out of the kernel Makefiles with an autoconf macro. No it doesn't. It works just fine. > Also, stock LiS is quite poor at handling distro kernels, because > it uses kernel.org version tests. The same autoconf macros I use > test kernel headers for specific patterns so adapt better to > production distro kernels that have various patches applied. This is also not true. The version that I have works fine on all SuSE and RH distros with 2.4 and 2.6 kernels. 32 and 64 bit. > > Is there any elegant way to 'steal' this CC options from LiS > > so that I will not need to get into a trouble of finding > > them from the kernel and sources again? > > I use the same autoconf macros for building packages against LiS > and LfS. You don't need to steal anything if you are using my version. Just use the kernel's module build Makefile and add -mregparam=0 to your flags. > > "Brian F. G. Bidulock" <[EMAIL PROTECTED]> wrote: > > >EugeneLisStreams, > > >Sometimes > > >#define _RP __attribute__((regparm(3))) > > >othertimes > > >#define _RP This also is not true. For 2.6 kernels you get: #define _RP __attribute__((regparm(0))) For 2.4 kernels you get: #define _RP -Dan _______________________________________________ Linux-streams mailing list [email protected] http://gsyc.escet.urjc.es/mailman/listinfo/linux-streams
