Right now we have a problem with struct sysinit.
The problem is that some SYSINIT functions supply a function taking
a const void * and a const pointer for data, and other SYSINIT
functions supply a function taking a void * and a non-const pointer
for data.
What this means, effectively, is that we want one of two SYSINIT
structures where both the function argument and udata are of the
same type. Something like the union shown below. If the function
argument type does not match the data type we want the initialization
to generate a warning.
struct sysinit {
unsigned int subsystem; /* subsystem identifier*/
unsigned int order; /* init order within subsystem*/
union {
struct {
void (*func) __P((void *));
void *udata; /* multiplexer/argument */
} n;
struct {
void (*func) __P((const void *));
const void *udata; /* multiplexer/argument */
} c;
} u;
si_elem_t type; /* sysinit_elem_type*/
};
Unfortunately, GCC isn't smart enough to match the function type
to the correct structure - it always stuffs it into the first structure.
So the above cool hack will not work :-(.
I can't think of how to do this without actually having two different
sysinit structures - on that uses a non-const function and data element,
and one that uses a const function and data element. While having two
sysinit structures would work, it would be a little iffy keeping them
in sync with each other so the kernel init call code doesn't have to deal
with both types.
struct c_sysinit {
unsigned int subsystem; /* subsystem identifier*/
unsigned int order; /* init order within subsystem*/
void (*func) __P((void *));
void *udata; /* multiplexer/argument */
si_elem_t type; /* sysinit_elem_type*/
};
struct n_sysinit {
unsigned int subsystem; /* subsystem identifier*/
unsigned int order; /* init order within subsystem*/
void (*func) __P((const void *));
const void *udata; /* multiplexer/argument */
si_elem_t type; /* sysinit_elem_type*/
};
The SYSINIT problem accounts for about half the remaining compilation
warnings. I would like to find a good solution for it.
-Matt
Matthew Dillon
<dil...@backplane.com>
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message
