From owner-svn-src-stable-9@FreeBSD.ORG Sat Dec 29 04:17:00 2012 Return-Path: Delivered-To: svn-src-stable-9@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [69.147.83.52]) by hub.freebsd.org (Postfix) with ESMTP id 1F532E4 for ; Sat, 29 Dec 2012 04:16:58 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vb0-f50.google.com (mail-vb0-f50.google.com [209.85.212.50]) by mx1.freebsd.org (Postfix) with ESMTP id 786E68FC16 for ; Sat, 29 Dec 2012 04:16:58 +0000 (UTC) Received: by mail-vb0-f50.google.com with SMTP id fr13so11423712vbb.9 for ; Fri, 28 Dec 2012 20:16:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=wemm.org; s=google; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=Sh1/aevNEsSdqE2sh6DmUt0HHeSm/vfXxow94RQlLWo=; b=jV9wLyy8H7nG/J3Uk7hS5/eTRX9YytAnS0/Ysn8DaYPGYgrWGRfnIlJF3krHyFPiFk mSfnB2ZAlSAKle0zAmSxIu2hjBUYONRIAaasTWl5y2qgrBS8qz0N/Fw3Fi7Zaupmcsrw 0xMGSO2kUy7DCTcvw5Ci6KAZvxN2HEoQrJaMY= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type:x-gm-message-state; bh=Sh1/aevNEsSdqE2sh6DmUt0HHeSm/vfXxow94RQlLWo=; b=Cg09dC8WCt1wctjRXTiApm869OpJnhYW15B0XVyq2QA8ehL4mdKWRg8OCnwRlvdr0e aoN0h3uPY6LR1/uU6lXAtxVP4VK+FreYVrm0TVXgjts+AUhvj0je96zxZ9c9Ns8MEfp0 x9Fj2zBXtvVacx+B0o8l8XA8fanZGiP6So2PCbgooaJi332cnYSe2lCaq2wafgU+Y4Ng 8cw9Ay3gO1JU5Wa/52mf6KwT1Xtz/srRoJJ0Mv5zrEMKvAkRhrLJkhfWV7hnuXgZqLYH Urlsjsga21V9dmPyGv0+C8RQL+pozAjzNERsBAS+H2hlxTSgdtkhutduzgzXLL5JOH4B pC4g== MIME-Version: 1.0 Received: by 10.52.69.201 with SMTP id g9mr46773171vdu.98.1356754611805; Fri, 28 Dec 2012 20:16:51 -0800 (PST) Received: by 10.220.205.6 with HTTP; Fri, 28 Dec 2012 20:16:51 -0800 (PST) In-Reply-To: References: <201212241422.qBOEMrcF021632@svn.freebsd.org> <50D8B533.8080507@mu.org> <20121225104422.GB53644@kib.kiev.ua> Date: Fri, 28 Dec 2012 20:16:51 -0800 Message-ID: Subject: Re: svn commit: r244663 - stable/9 From: Peter Wemm To: Robert Watson Content-Type: text/plain; charset=ISO-8859-1 X-Gm-Message-State: ALoCoQlB+2ZzKUf6tS0Gk9YfYK9GB5aXtCS78oBNdc4UuoHDlgBu6UBXHkWMlL6IMhrH5yW+78pV Cc: Adrian Chadd , src-committers@freebsd.org, svn-src-stable@freebsd.org, svn-src-all@freebsd.org, Alfred Perlstein , svn-src-stable-9@freebsd.org, Konstantin Belousov X-BeenThere: svn-src-stable-9@freebsd.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: SVN commit messages for only the 9-stable src tree List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2012 04:17:00 -0000 On Tue, Dec 25, 2012 at 11:17 AM, Robert Watson wrote: > On Tue, 25 Dec 2012, Konstantin Belousov wrote: > >> On Mon, Dec 24, 2012 at 12:04:03PM -0800, Alfred Perlstein wrote: >>> >>> On 12/24/12 11:24 AM, Adrian Chadd wrote: >>>> >>>> ... why'd we break the KBI in a stable branch? >>>> >>> I am not sure either. >>> >>> I think a single VOP for nullfs (while ugly) would have sufficed. >> >> No, it doesn't. >> >> Even if it would be sufficient, having a switch right after the vtable >> call is silly. But, ignoring the sillyness, having a single VOP forces a >> filesystem, needed to override the single bit of behaviour, to override all >> behaviours hidden from under the common VOP. Besides the incovenience, it >> breaks the bypass. This is why I did not went this route in the HEAD commit. >> >> Making HEAD and stable diverge for the VOP table is unmaintainable. >> >> At least one other change which cannot be covered by the VOP table hacking >> is the struct vfsops new method. >> >> Traditionally (my memory goes back to 6.x branch) we did not maintained >> VFS KBI stability on the branches. > > > While I would love to have a stable KBI, or even KPI, for VFS, past > experience suggests that we are not prepared to document one, let alone > enforce it, and that we frequently experience changes that disrupt both the > binary and programming interfaces -- often for very good reasons (e.g., > fixing critical bugs, improving performance, etc). And that the notional > VFS KPI is extremely promiscuous, being made up of not just the obvious VFS > parts, but also VM parts, etc. For what its worth, we used to have an extensible VOP_* interface that didn't have this sort of problem. It was removed in r140165 (back in 2005) and we gained a whole bunch of extra functionality afterwards including type checking. -- Peter Wemm - peter@wemm.org; peter@FreeBSD.org; peter@yahoo-inc.com; KI6FJV bitcoin:188ZjyYLFJiEheQZw4UtU27e2FMLmuRBUE