From owner-svn-src-all@FreeBSD.ORG Sat Dec 29 10:50:04 2012 Return-Path: Delivered-To: svn-src-all@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id ABB30D84; Sat, 29 Dec 2012 10:50:04 +0000 (UTC) (envelope-from rwatson@freebsd.org) Received: from cyrus.watson.org (cyrus.watson.org [65.122.17.42]) by mx1.freebsd.org (Postfix) with ESMTP id 748AD8FC08; Sat, 29 Dec 2012 10:50:04 +0000 (UTC) Received: from [192.168.2.119] (host86-129-88-139.range86-129.btcentralplus.com [86.129.88.139]) by cyrus.watson.org (Postfix) with ESMTPSA id 92B7446B1A; Sat, 29 Dec 2012 05:50:02 -0500 (EST) Subject: Re: svn commit: r244663 - stable/9 Mime-Version: 1.0 (Apple Message framework v1283) Content-Type: text/plain; charset=iso-8859-1 From: "Robert N. M. Watson" In-Reply-To: <50DE74F1.70105@mu.org> Date: Sat, 29 Dec 2012 10:49:59 +0000 Content-Transfer-Encoding: quoted-printable Message-Id: References: <201212241422.qBOEMrcF021632@svn.freebsd.org> <50D8B533.8080507@mu.org> <20121225104422.GB53644@kib.kiev.ua> <50DE74F1.70105@mu.org> To: Alfred Perlstein X-Mailer: Apple Mail (2.1283) Cc: Adrian Chadd , src-committers@freebsd.org, Peter Wemm , svn-src-stable@freebsd.org, svn-src-all@freebsd.org, svn-src-stable-9@freebsd.org, Konstantin Belousov X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2012 10:50:04 -0000 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=