Kevin,
Some gcc compilers (and it looks like you're using an older one), don't
detect regparm attribute mismatches in pointers when regparms is pass
as a option to the compiler, that is:
int (*foo)(int) __attribute__((regparm,0));
int bar(int dummy) {
return (dummy);
}
foo = &bar; /* should generate an error -regparm=3, but doesn't */
therefore, even though qinit is defined in include/sys/LiS/queue.h as:
typedef struct qinit {
#if defined(USE_VOID_PUT_PROC)
void _RP (*qi_putp) (queue_t *, mblk_t *); /* put procedure */
void _RP (*qi_srvp) (queue_t *); /* service procedure */
#else
int _RP (*qi_putp) (queue_t *, mblk_t *); /* put procedure */
int _RP (*qi_srvp) (queue_t *); /* service procedure */
#endif
int _RP (*qi_qopen) (queue_t *, dev_t *, int, int, cred_t *);
int _RP (*qi_qclose) (queue_t *, int, cred_t *); /* close
procedure */
int _RP (*qi_qadmin) (void); /* debugging */
struct lis_module_info *qi_minfo; /* module information structure
*/
struct module_stat *qi_mstat; /* module statistics structure */
} qinit_t;
Where _RP is __attribute__((regparm,0)) on regparm supporting architectures,
you can do this:
int foo_open(queue_t *q, dev_t *devp, int oflag, int sflag, cred_t *crp) {
...
return (0);
}
int foo_close(queue_t *q, int oflag, cred_t *crp) {
...
return (0);
}
struct qinit foo_rinit = {
...
.qi_qopen = &foo_open,
.qi_qclose = &foo_close,
...
};
and when compiled with -regparms=3, older gcc3 compilers will not warn of the
mismatch.
If you do, however,
int _RP foo_open(queue_t *q, dev_t *devp, int oflag, int sflag, cred_t *crp) {
...
return (0);
}
int _RP foo_close(queue_t *q, int oflag, cred_t *crp) {
...
return (0);
}
There is no mismatch and no problem. So, try that.
For Linux Fast-STREAMS, the equivalent is 'streamscall', so
int streamscall foo_open(queue_t *q, dev_t *devp, int oflag, int sflag,
cred_t *crp) {
...
return (0);
}
int streamscall foo_close(queue_t *q, int oflag, cred_t *crp) {
...
return (0);
}
Under Linux Fast-STREAMS, streamscall is __attribute__((regparm,3)) on
supporting architectures, so if you forget the streamscall you will only
encounter problems on non-regparms kernels (for architectures support
regparms). The result is of course faster than LiS on ia32 architectures.
Hope that helps.
BTW, the current Linux Fast-STREAMS works *way* better than LiS.
--brian
On Mon, 27 Mar 2006, Kevin K wrote:
> Has anyone else noticed a problem with the Redhat Kernel compiled
> with the default register parameters?
>
> I'm looking at porting a legacy set of modules written for LiS 2.12
> and the 2.4.18 kernel to the Red Hat 2.6.9-34 kernel.
>
> The initial problem I encountered was that the open routine in the
> module was getting garbage in it's parameter. I enabled debug
> output, and it showed that, just before it called my routine, it had
> the right parameters.
>
> Finally, I ended up recompiling the kernel again with regparms turned
> off, and recompiled LiS correctly. I required a modification to the
> Makefile, since the configure script didn't retrieve the
> configuration options correctly, then it finally started to work.
>
> Note, I haven't tried the most recent version of Fast Streams yet. I
> couldn't get the streams module to load successfully in the January
> version. Unfortunately, I didn't save any of the error output. I
> may give it another try in the not to distant future, if only because
> if it works, it will save a considerable amount of memory. It is
> hard to believe how much memory the current version of streams is
> taking up :)
> _______________________________________________
> 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
