Date: Sat, 29 Dec 2012 10:49:59 +0000 From: "Robert N. M. Watson" <rwatson@freebsd.org> To: Alfred Perlstein <bright@mu.org> Cc: Adrian Chadd <adrian@freebsd.org>, src-committers@freebsd.org, Peter Wemm <peter@wemm.org>, svn-src-stable@freebsd.org, svn-src-all@freebsd.org, svn-src-stable-9@freebsd.org, Konstantin Belousov <kostikbel@gmail.com> Subject: Re: svn commit: r244663 - stable/9 Message-ID: <C256AEF0-E68E-4C15-9A00-3465C89DD51D@freebsd.org> In-Reply-To: <50DE74F1.70105@mu.org> References: <201212241422.qBOEMrcF021632@svn.freebsd.org> <CAJ-VmokV-JL_xZ9otRXubKZ8KQKe7GgLuLU3UMij0HUD_KhCNw@mail.gmail.com> <50D8B533.8080507@mu.org> <20121225104422.GB53644@kib.kiev.ua> <alpine.BSF.2.00.1212251911360.56707@fledge.watson.org> <CAGE5yCp1oVe74_8wot8rJe5BU9uOHyfLipUN0cFtCC77CLo8hA@mail.gmail.com> <50DE74F1.70105@mu.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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. >=20 > 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=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C256AEF0-E68E-4C15-9A00-3465C89DD51D>