This is a discussion on Re: [PATCH] Automatic kernel version module dependencies.. - FreeBSD ; On Sunday 10 February 2008 06:24:37 am Dag-Erling Sm=C3=B8rgrav wrote: > "M. Warner Losh" writes: > > Dag-Erling_Sm=C3=B8rgrav writes: > > > ...provided they were built from the same config... I think > > > MUTEX_PROFILING has been fixed, but ...
On Sunday 10 February 2008 06:24:37 am Dag-Erling Sm=C3=B8rgrav wrote:
> "M. Warner Losh"
> > Dag-Erling_Sm=C3=B8rgrav
> > > ...provided they were built from the same config... I think
> > > MUTEX_PROFILING has been fixed, but there may still be cases where
> > > the ABI changes dependening on kernel options.
> > These are usually well documented. But I can't find any in the
> > current doc set. Maybe you could point me at options that do this so
> > we can document them (and maybe add a #warning when compiling with
> > them)?
> Here's one I found: DEBUG_LOCKS changes the size of struct lock, which
> changes the size and layout of struct vnode.
Yes, DEBUG_LOCKS, MUTEX_PROFILING (O.B.E), and PAE are the ones I know of. =
could employ a similar strategy for these btw. For example, you could do=20
this for PAE:
#define PAE_DEPEND(name) MODULE_DEPEND(name, pae, 1, 1, 1)
#define PAE_DEPEND(name) MODULE_DEPEND(name, pae, 0, 0, 0)
#define PAE_DEPEND(name) struct __hack
#define DECLARE_MODULE(name, ...) \
It sucks to have the MD-ness there. Could perhaps have an MI macro like th=
#define MACHINE_MODULE_DEPEND struct __hack
PAE bits from above but s/PAE_DEPEND/MACHINE_MODULE_DEPEND/. In general we=
try to keep the number of such ABI-breaking options to a very bare minimum,=
so perhaps one-off hacks in sys/module.h rather than abstracting it is=20
email@example.com mailing list
To unsubscribe, send any mail to "firstname.lastname@example.org"