From owner-svn-src-all@FreeBSD.ORG Sat Dec 29 04:16:52 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 DA775ED9 for ; Sat, 29 Dec 2012 04:16:52 +0000 (UTC) (envelope-from peter@wemm.org) Received: from mail-vc0-f171.google.com (mail-vc0-f171.google.com [209.85.220.171]) by mx1.freebsd.org (Postfix) with ESMTP id 7B0858FC13 for ; Sat, 29 Dec 2012 04:16:52 +0000 (UTC) Received: by mail-vc0-f171.google.com with SMTP id n11so11279067vch.16 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=IbOy1CyROxI2dhTb8jM7g7zEXDXewg9UL3EAg5wEguT895HbiDmx3VJmjvRPGpbn1c 9gVBn3wJtYpu2i4Bd+XWRiqE/ilnpm2Xg7OwG6GmXJ74nAaqpzILzKfO6ljv32yQqtUm PwuWiX16aOKlOjJg4Jnj7iZX76v/ND/zyO+ESBuhLkT/Y2HMSSON47Uv6qkDeaz4K7Ro +aCbcKcG9zhnKPDDZQ/uXid9IU2SMer5FjG6KkVHhIC5aHHejquxW3BrgfE16/daHQw6 6U1kOimR2wHsSb6owW5R6Go4hojM0gsXF4wzpcAgNEM/D6VK59NYD9RewhBPVVOn8uvU 2TBA== 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: ALoCoQk4m6ylXrpbxzG1MqUXniCbO+t3449/qADN2goisVF5H3jViStvgpriT7Nv0ge7+jEvNNSg 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-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 04:16:52 -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