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 ...

[Robert Watson]

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