HEADSUP ABI breakage for future LOCK_PROFILING +
non-LOCK_PROFILING usage
Kip Macy
kip.macy at gmail.com
Tue Feb 27 20:18:11 UTC 2007
Good point about the struct mtx being embedded in arbitrary places in
structures. I'll need to rethink.
On 2/27/07, John Baldwin <jhb at freebsd.org> wrote:
> On Tuesday 27 February 2007 01:30, Kip Macy wrote:
> > The following change will go in shortly unless I hear a good reason
> > not to do so.
> >
> > -Kip
> >
> > 200702246:
> > The lock_profile_object in the lock_object has been moved to the
> > bottom and lock_object ha been moved to the end of all synchronization
> > primitives so that a kernel compiled without LOCK_PROFILING will
> > work with modules that are compiled with it. It also gets us closer
> > to having a kernel compiled with LOCK_PROFILING work with modules
> > compiled without. The kernel and all modules will need to be
> > re-compiled.
>
> The kernel + modules compiled together should already work if LOCK_PROFILING
> is defined when the modules are built, and the new kernel build glue is
> supposed to do that for you already.
>
> However, this won't help with mixing the PROFILING and non-PROFILING cases
> because 'struct mtx' will still be variant sized and several structures
> have 'struct mtx' embedded in them (most notably struct proc) and having
> 'struct mtx' change size breaks the ABI because the offsets of all the
> members after 'p_mtx' change. E.g. all the p->p_vmspace offsets would be
> different in the LOCK_PROFILING vs non-LOCK_PROFILING kernels.
>
> Also, this would break the ddb 'show lock' command, though that may be less
> important.
>
> --
> John Baldwin
>
More information about the freebsd-current
mailing list