Date: Fri, 16 Feb 2007 09:25:31 -0700 From: "Coleman Kane" <zombyfork@gmail.com> To: "Robert Watson" <rwatson@freebsd.org> Cc: cvs-src@freebsd.org, src-committers@freebsd.org, Pawel Jakub Dawidek <pjd@freebsd.org>, 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 ... Message-ID: <346a80220702160825m305123cbrd0d7f0bfcc98303b@mail.gmail.com> In-Reply-To: <20070216100310.J83539@fledge.watson.org> References: <200702152208.l1FM8aY7002188@repoman.freebsd.org> <20070216073206.C83539@fledge.watson.org> <20070216085810.GB55867@garage.freebsd.pl> <20070216100310.J83539@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2/16/07, Robert Watson <rwatson@freebsd.org> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?346a80220702160825m305123cbrd0d7f0bfcc98303b>