Date: Tue, 27 Feb 2007 15:15:07 -0500 From: John Baldwin <jhb@freebsd.org> To: freebsd-current@freebsd.org Cc: Kip Macy <kip.macy@gmail.com> Subject: Re: HEADSUP ABI breakage for future LOCK_PROFILING + non-LOCK_PROFILING usage Message-ID: <200702271515.08052.jhb@freebsd.org> In-Reply-To: <b1fa29170702262230q2d2e1b03i362a4af4ec0bd595@mail.gmail.com> References: <b1fa29170702262230q2d2e1b03i362a4af4ec0bd595@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200702271515.08052.jhb>