Re: HEADSUP ABI breakage for future LOCK_PROFILING + non-LOCK_PROFILING usage

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
>