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 alfred at
Wed Feb 21 20:39:26 UTC 2007

* Robert Watson <rwatson at> [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

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

More information about the cvs-src mailing list