From owner-svn-src-all@FreeBSD.ORG Tue Dec 25 10:44:31 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 D23499B5; Tue, 25 Dec 2012 10:44:31 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) by mx1.freebsd.org (Postfix) with ESMTP id 365F58FC0A; Tue, 25 Dec 2012 10:44:30 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.5/8.14.5) with ESMTP id qBPAiMUJ057147; Tue, 25 Dec 2012 12:44:22 +0200 (EET) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.7.3 kib.kiev.ua qBPAiMUJ057147 Received: (from kostik@localhost) by tom.home (8.14.5/8.14.5/Submit) id qBPAiM7N057146; Tue, 25 Dec 2012 12:44:22 +0200 (EET) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Tue, 25 Dec 2012 12:44:22 +0200 From: Konstantin Belousov To: Alfred Perlstein Subject: Re: svn commit: r244663 - stable/9 Message-ID: <20121225104422.GB53644@kib.kiev.ua> References: <201212241422.qBOEMrcF021632@svn.freebsd.org> <50D8B533.8080507@mu.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="03sphU6jKm9HdgU1" Content-Disposition: inline In-Reply-To: <50D8B533.8080507@mu.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-2.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FROM,NML_ADSP_CUSTOM_MED autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on tom.home Cc: svn-src-stable@freebsd.org, Adrian Chadd , src-committers@freebsd.org, svn-src-all@freebsd.org, svn-src-stable-9@freebsd.org 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: Tue, 25 Dec 2012 10:44:31 -0000 --03sphU6jKm9HdgU1 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable 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. >=20 > 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. --03sphU6jKm9HdgU1 Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.19 (FreeBSD) iQIcBAEBAgAGBQJQ2YOFAAoJEJDCuSvBvK1B/ssQAISdLaNUORMPE9M20P0KttJa /myrd3mS4K9RcKqOY3RJ7rrDQwpPie+gS/B/35wYdiREp4oJdCIZRe6qNWm7bzpJ N5Q3uu+WVcOasw4IM9H8CwwNWcZIQJiLh9tm1vMYaoFp8hhUfWp4vvpMelKNR8v0 rztOuF2ql6nj7/RD+cmrODkf4BgAeQq8Sl4zr1HY/Mk0F+O6ik5n3rwTUi+2Uq0f B1j6tW3u8fx8nF1H/kowQ58H6aH+KhcKyvA7oUVYOQK3jLX8tR5KmU10zflOrGn9 yEooI/xJKWFdyZrryiSoF9zcLkjOexlE/4GxgaZuio+CHs0Wn3ZMQAhhCnOiNPCe QE8JOKgPwdOlQAE7q6r8VXNqQylcPZlvbmuhee+rfjx9IXjBi75FAxxuj3PLWyOg RjEHuXGj844rWxGqcsOKwMKMjC2s8KC9J8HcAN8Yz8ogN6sIVflXSra463aEloQP YBnW3j2dkHiYTpuj9v8/DweUzi6C3Bca2Z+wqnedn9UWIRaTccnfcTAtx2EfeLDq mm/c95RL20HzjzLewy8NnlX5rMexJXfs0Y7rKOCd6wigu+HpWDk1IkutczMnwxqg kAFfiJnYnnWqPz+WNiWo7cv0z+t/JJ+LkvTb2D8AZIkwj8Ln0vf6bXoDAaI/RwRc 5jilHzVtYYYz/D37xD4u =/Axn -----END PGP SIGNATURE----- --03sphU6jKm9HdgU1--