From owner-cvs-all@FreeBSD.ORG Tue Feb 26 13:29:58 2008 Return-Path: Delivered-To: cvs-all@FreeBSD.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id CF56E1065670; Tue, 26 Feb 2008 13:29:58 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from cyrus.watson.org (cyrus.watson.org [209.31.154.42]) by mx1.freebsd.org (Postfix) with ESMTP id 886DB13C4E5; Tue, 26 Feb 2008 13:29:58 +0000 (UTC) (envelope-from rwatson@FreeBSD.org) Received: from fledge.watson.org (fledge.watson.org [209.31.154.41]) by cyrus.watson.org (Postfix) with ESMTP id A893046B0D; Tue, 26 Feb 2008 08:29:57 -0500 (EST) Date: Tue, 26 Feb 2008 13:29:57 +0000 (GMT) From: Robert Watson X-X-Sender: robert@fledge.watson.org To: =?utf-8?Q?Dag-Erling_Sm=C3=B8rgrav?= In-Reply-To: <86r6ezswnu.fsf@ds4.des.no> Message-ID: <20080226132155.W90776@fledge.watson.org> References: <200802250855.m1P8t3w6052042@repoman.freebsd.org> <47C29A07.2070908@FreeBSD.org> <86d4qli8a1.fsf@ds4.des.no> <20080226123107.N90776@fledge.watson.org> <86r6ezswnu.fsf@ds4.des.no> MIME-Version: 1.0 Content-Type: MULTIPART/MIXED; BOUNDARY="621616949-710383528-1204032597=:90776" Cc: cvs-src@FreeBSD.org, Kris Kennaway , src-committers@FreeBSD.org, cvs-all@FreeBSD.org, "David E. O'Brien" Subject: Re: cvs commit: src/sys/fs/nullfs null_vfsops.c src/sys/fs/nwfs nwfs_vfsops.c src/sys/fs/smbfs smbfs_vfsops.c src/sys/ufs/ufs quota.h ufs_quota.c ufs_vfsops.c src/sys/kern vfs_default.c vfs_vnops.c vnode_if.src src/sys/sys mount.h vnode.h X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Feb 2008 13:29:59 -0000 This message is in MIME format. The first part should be readable text, while the remaining parts are likely unreadable without MIME-aware tools. --621616949-710383528-1204032597=:90776 Content-Type: TEXT/PLAIN; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: QUOTED-PRINTABLE On Tue, 26 Feb 2008, Dag-Erling Sm=F8rgrav wrote: > Robert Watson writes: >> Dag-Erling Sm=F8rgrav writes: >>> No, it changes neither the API nor the ABI. It replaces caddr_t (which= is=20 >>> typedef'd to char *) with void *, and those two are compatible types. >> I'm sorry, but I disagree. The case you failed to test involves a funct= ion=20 >> pointer typedef. > > Umm, OK, I didn't spot that. It's unfortunate that David didn't change o= ur=20 > own file system code to match (or even build LINT, which would have shown= =20 > him the problem), so that RELENG_6 current doesn't build. > > Still, I would argue for fixing the code rather than reverting the change= =2E > >> Here's the test I had to add to Arla to detect the change with autoconf;= =20 >> without this autoconf mess and changed prototypes in the Arla nnpfs code= , I=20 >> can't build nnpfs on -CURRENT, and presumably now also on our -STABLE=20 >> branches: > > Arguably, Arla has been broken for more than two years and you only just= =20 > woke up and noticed. If you had tried to build Arla on -CURRENT at any= =20 > point since 2005/12/14, you would have noticed and presumably fixed it. You're missing the point. This isn't about Arla being broken on 7.x and 8.= x=20 -- we knew that already, and hence my already having autoconf code to detec= t=20 and adapt to the difference in the 7.x and 8.x KPIs. What this is about is= =20 the fact that Arla *did* work on 6.x before this change, and now it's broke= n.=20 This is because the KPI has been broken, as our KPI definition is pretty=20 pragmatic (undocumented): third party kernel modules that implement the=20 quotactl vfsop may well no longer compile. I couldn't tell you which those= =20 are off-hand, but it wouldn't surprise me to hear that there are other thir= d=20 party kernel modules that declare quotactl implementations. I'm fine with us discussing how committed we are to VFS being a KPI we don'= t=20 break in -STABLE branches, but I'm not fine with the claim that the KPI was= n't=20 broken by this change. If pushed on the breaking the KPI point, I would co= me=20 down on the side that says 6.x is a pretty mature branch at this point, and= =20 that breaking the KPI for purely cosmetic reasons (i.e., caddr_t -> void *)= =20 doesn't cut it. I would be more swayed by an argument involving a necessar= y=20 KPI change to address a critical bugfix, such as a race condition that resu= lts=20 from a poor existing interface. Robert N M Watson Computer Laboratory University of Cambridge --621616949-710383528-1204032597=:90776--