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

[Alfred Perlstein]

* Robert Watson <rwatson at FreeBSD.org> [070216 02:05] wrote:
> 
> On Fri, 16 Feb 2007, Pawel Jakub Dawidek wrote:
> 
> >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.

Since there appears to be only one non-core (for now) fs that needs
this facility it's a bit surprising that it can't be made to be
compatible.

The old VFS_VPTOFH macro could just return EOPNOTSUP for filesystem
consumers that use it on non-supporting filesystems.

Filesystems that don't need the new VOP version could make use of
a default op that just calls the old style VFS operation.

Not that is has to be done this way, but I'm just saying, there was
little need to kneecap our third party developers. :)

-- 
- Alfred Perlstein