svn commit: r244663 - stable/9

[Robert N. M. Watson]

On 29 Dec 2012, at 04:43, Alfred Perlstein wrote:

> Yes.  Kib and I chatted offline, it seems that the SOP is really "there is no guarantee about KPI when talking about VFS" so the headache that it would be to write the shim layer and maintain it (particularly considering the 9.x release cycle slowness) was not worth it.
> 
> In a few days I'm going to blow up the extra entries in VFSOPS and VOPS by some 10 entries to hopefully keep us KPI friendly for the next release.  I may also introduce a VFS_KPI version number.  Let me know if you have any thoughts on that, my thoughts are basically to make it like FreeBSD_version, and eventually someone can add macros for VFS klds to refuse to load depending on VFS_KPI.

I don't think stub entries hurt.

But I think a VFS_KPI version number is premature.

Go about this forwards, not backwards:

First, select an existing base system VFS module that you think is a reasonable model for feature dependency footprint -- i.e., one that doesn't reach into too many ugly things, and "behaves well". Maybe ext2fs is a reasonable one to use. Then do a binary feature footprint analysis: run "nm" on the module and see what it actually depends on, and enumerate those on a wiki page.

That becomes the foundation for the KBI. KPI is more tricky, since it will likely include lots of headers it doesn't need, etc, but you can start to work back to the KPI from the KBI. Pay particular attention to key data structures -- in the network stack, this wasn't just network-related structures like ifnet and mbuf, but also all newbus-related structures, lock data structures, etc.

FWIW, on the device driver side I think we did the casual analysis based on if_em, which we felt would be "typical".

Finally, go to the extant external modules for VFS -- probably limited to FUSE (which will not matter soon as FUSE will be in the base soon), and OpenAFS ... perhaps one or two others. Do a similar analysis there and decide if there are enough external modules that play by the proposed KPI and KBI to justify enforcing the rules.

Along the way, do keep asking yourself "is this worth it" -- if, with the FUSE import, we're down to one extant open source third-party file system, then it probably isn't, to be honest. The tradeoff just falls down on the other side. On the other hand, if there are a half-dozen of them, and there are lots of companies that have internal modules that would observe the KPI /KBI, then it may be worth it.

Robert