From owner-cvs-all@FreeBSD.ORG Fri Feb 16 16:25:33 2007 Return-Path: X-Original-To: cvs-all@freebsd.org Delivered-To: cvs-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 045C816A46D for ; Fri, 16 Feb 2007 16:25:33 +0000 (UTC) (envelope-from zombyfork@gmail.com) Received: from nz-out-0506.google.com (nz-out-0506.google.com [64.233.162.234]) by mx1.freebsd.org (Postfix) with ESMTP id 8DFB613C4A7 for ; Fri, 16 Feb 2007 16:25:32 +0000 (UTC) (envelope-from zombyfork@gmail.com) Received: by nz-out-0506.google.com with SMTP id i11so1046969nzh for ; Fri, 16 Feb 2007 08:25:31 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:reply-to:to:subject:cc:in-reply-to:mime-version:content-type:references; b=o/MWIYtll/UUpHT6pqbelSXvo40YSk4k3rNOemQgJQURqLPe2rrpSmwZv1dKCkcE02OWYqTy3Vp8/k1N8kLRoXizRFuqJI4vaBUxAXX6JF9YZzIBUXGaPfPGemlImetKNq/8sBV3igsmFf2IJSk/hPwMbOk/bp+3MLUI5NPjhE4= Received: by 10.65.241.20 with SMTP id t20mr5174389qbr.1171643131662; Fri, 16 Feb 2007 08:25:31 -0800 (PST) Received: by 10.49.63.7 with HTTP; Fri, 16 Feb 2007 08:25:31 -0800 (PST) Message-ID: <346a80220702160825m305123cbrd0d7f0bfcc98303b@mail.gmail.com> Date: Fri, 16 Feb 2007 09:25:31 -0700 From: "Coleman Kane" To: "Robert Watson" In-Reply-To: <20070216100310.J83539@fledge.watson.org> MIME-Version: 1.0 References: <200702152208.l1FM8aY7002188@repoman.freebsd.org> <20070216073206.C83539@fledge.watson.org> <20070216085810.GB55867@garage.freebsd.pl> <20070216100310.J83539@fledge.watson.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline X-Content-Filtered-By: Mailman/MimeDel 2.1.5 Cc: cvs-src@freebsd.org, src-committers@freebsd.org, Pawel Jakub Dawidek , cvs-all@freebsd.org Subject: Re: cvs commit: src/sys/fs/hpfs hpfs_vfsops.c hpfs_vnops.c src/sys/fs/msdosfs msdosfs_vfsops.c msdosfs_vnops.c src/sys/fs/ntfs ntfs_vfsops.c ntfs_vnops.c src/sys/fs/nullfs null_vfsops.c null_vnops.c src/sys/fs/udf udf.h udf_vfsops.c ... X-BeenThere: cvs-all@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: cokane@cokane.org List-Id: CVS commit messages for the entire tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Feb 2007 16:25:33 -0000 On 2/16/07, Robert Watson wrote: > > > On Fri, 16 Feb 2007, Pawel Jakub Dawidek wrote: > > > On Fri, Feb 16, 2007 at 07:33:12AM +0000, Robert Watson wrote: > >> > >> On Thu, 15 Feb 2007, Pawel Jakub Dawidek wrote: > >> > >>> Move vnode-to-file-handle translation from vfs_vptofh to vop_vptofh > method. > >>> This way we may support multiple structures in v_data vnode field > within > >>> one file system without using black magic. > >>> > >>> Vnode-to-file-handle should be VOP in the first place, but was made > VFS > >>> operation to keep interface as compatible as possible with SUN's VFS. > >>> BTW. Now Solaris also implements vnode-to-file-handle as VOP > operation. > >>> > >>> VFS_VPTOFH() was left for API backward compatibility, but is marked > for > >>> removal before 8.0-RELEASE. > >>> > >>> Approved by: mckusick > >>> Discussed with: many (on IRC) > >>> Tested with: ufs, msdosfs, cd9660, nullfs and zfs > >> > >> Do you think API backward compatibility is actually required in 7.x > ? It > >> looks like you've updated all the file systems, in which case the > >> temptation would be to drop it as we already have other VFS changes in > 7.x > >> from 6.x. > > > > Those changes break API or only ABI? My change break ABI backward > > compatibility, but I thought it will be good to leave API compatibility > so > > 3rd party file systems (eg. from ports) have time to catch-up. If this > is > > not necessary, I'll remove it right away. > > I'd rather we forced the breakage sooner, as ports may not get fixed if > they > don't get broken. :-) Doing it now maximizes the amount of time for > these > changes to settle, and mean that new work will be done to the new > APIs. If > there were MFC plans for this, then having compatibility APIs in the MFC > is > important, of course. > > Robert N M Watson > Computer Laboratory > University of Cambridge Patches to fix the brokenness in these ports can always be applied through the ports system until the author gets around to fixing them, so I think this is a good move. I fancy the approach of moving forward this development as quickly as possible. Especially while 7.0 is still under development. -- coleman