From owner-freebsd-stable@FreeBSD.ORG Wed Jul 30 19:05:42 2008 Return-Path: Delivered-To: freebsd-stable@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 746A2106566B for ; Wed, 30 Jul 2008 19:05:42 +0000 (UTC) (envelope-from modelnine@modelnine.org) Received: from jord.modelnine.org (jord.modelnine.org [83.246.72.120]) by mx1.freebsd.org (Postfix) with ESMTP id 3910A8FC17 for ; Wed, 30 Jul 2008 19:05:41 +0000 (UTC) (envelope-from modelnine@modelnine.org) Received: from phoenix (port-92-196-44-243.dynamic.qsc.de [92.196.44.243]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: modelnine) by jord.modelnine.org (Postfix) with ESMTPSA id A0EB6A40CC0; Wed, 30 Jul 2008 21:05:40 +0200 (CEST) From: Heiko Wundram To: Kostik Belousov Date: Wed, 30 Jul 2008 21:09:38 +0200 User-Agent: KMail/1.9.7 References: <1217346345.12322.31.camel@bauer.cse.buffalo.edu> <200807301326.33227.modelnine@modelnine.org> <20080730113031.GS97161@deviant.kiev.zoral.com.ua> In-Reply-To: <20080730113031.GS97161@deviant.kiev.zoral.com.ua> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807302109.39405.modelnine@modelnine.org> Cc: freebsd-stable@freebsd.org Subject: Re: Upcoming ABI Breakage in RELENG_7 X-BeenThere: freebsd-stable@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Production branch of FreeBSD source code List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 30 Jul 2008 19:05:42 -0000 Am Mittwoch, 30. Juli 2008 13:30:31 schrieben Sie: > I do not use the fuse fs myself. But the issue was raised during the > internal discussion of the MFC, and it seems that fuse could be not > affected. > > The change only adds the field at the end of the vnode structure, so all > existing fields offsets are intact. I just half-throughly waded through the sysutils/fusefs-kmod sources, and you're right; there's no mentioning of sizeof(struct vnode) in all of the preprocessed sources (at least none that I could find, directly or indirectly). So, if struct vnode only grows and none of the original fields are moved due to padding issues (or gcc reordering fields because of padding), the old kernel module should work unchanged. To finish: sorry for the noise, and sorry for the panic I might've provoked. -- Heiko Wundram