From owner-freebsd-current@FreeBSD.ORG Tue Feb 27 20:14:42 2007 Return-Path: X-Original-To: freebsd-current@freebsd.org Delivered-To: freebsd-current@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 4002A16A402 for ; Tue, 27 Feb 2007 20:14:42 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from server.baldwin.cx (66-23-211-162.clients.speedfactory.net [66.23.211.162]) by mx1.freebsd.org (Postfix) with ESMTP id DC7AE13C467 for ; Tue, 27 Feb 2007 20:14:41 +0000 (UTC) (envelope-from jhb@freebsd.org) Received: from localhost.corp.yahoo.com (john@localhost [127.0.0.1]) (authenticated bits=0) by server.baldwin.cx (8.13.8/8.13.8) with ESMTP id l1RKEd0F053149; Tue, 27 Feb 2007 15:14:39 -0500 (EST) (envelope-from jhb@freebsd.org) From: John Baldwin To: freebsd-current@freebsd.org Date: Tue, 27 Feb 2007 15:15:07 -0500 User-Agent: KMail/1.9.1 References: In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200702271515.08052.jhb@freebsd.org> X-Greylist: Sender succeeded SMTP AUTH authentication, not delayed by milter-greylist-2.0.2 (server.baldwin.cx [127.0.0.1]); Tue, 27 Feb 2007 15:14:40 -0500 (EST) X-Virus-Scanned: ClamAV 0.88.3/2665/Tue Feb 27 11:26:03 2007 on server.baldwin.cx X-Virus-Status: Clean X-Spam-Status: No, score=-4.4 required=4.2 tests=ALL_TRUSTED,AWL,BAYES_00 autolearn=ham version=3.1.3 X-Spam-Checker-Version: SpamAssassin 3.1.3 (2006-06-01) on server.baldwin.cx Cc: Kip Macy Subject: Re: HEADSUP ABI breakage for future LOCK_PROFILING + non-LOCK_PROFILING usage X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 27 Feb 2007 20:14:42 -0000 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