From owner-svn-src-head@FreeBSD.ORG Wed Sep 24 14:23:45 2014 Return-Path: Delivered-To: svn-src-head@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 1F719C2D; Wed, 24 Sep 2014 14:23:45 +0000 (UTC) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 80CA02E0; Wed, 24 Sep 2014 14:23:44 +0000 (UTC) Received: from tom.home (kostik@localhost [127.0.0.1]) by kib.kiev.ua (8.14.9/8.14.9) with ESMTP id s8OENdYs022052 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 24 Sep 2014 17:23:39 +0300 (EEST) (envelope-from kostik@tom.home) DKIM-Filter: OpenDKIM Filter v2.9.2 kib.kiev.ua s8OENdYs022052 Received: (from kostik@localhost) by tom.home (8.14.9/8.14.9/Submit) id s8OENdfa022051; Wed, 24 Sep 2014 17:23:39 +0300 (EEST) (envelope-from kostik) Date: Wed, 24 Sep 2014 17:23:39 +0300 From: Konstantin Belousov To: John Baldwin Subject: Re: svn commit: r272032 - head/sys/conf Message-ID: <20140924142339.GJ8870@kib.kiev.ua> References: <201409231704.s8NH4Lcv098184@svn.freebsd.org> <5421BC8E.6000709@FreeBSD.org> <20140923184434.GG8870@kib.kiev.ua> <8280436.uSRo73F0Mt@ralph.baldwin.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8280436.uSRo73F0Mt@ralph.baldwin.cx> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Status: No, score=0.2 required=5.0 tests=ALL_TRUSTED, DKIM_ADSP_CUSTOM_MED,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.0 X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on tom.home Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org, Bryan Drewery X-BeenThere: svn-src-head@freebsd.org X-Mailman-Version: 2.1.18-1 Precedence: list List-Id: SVN commit messages for the src tree for head/-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 24 Sep 2014 14:23:45 -0000 On Wed, Sep 24, 2014 at 09:58:07AM -0400, John Baldwin wrote: > On Tuesday, September 23, 2014 09:44:34 PM Konstantin Belousov wrote: > > On Tue, Sep 23, 2014 at 01:31:42PM -0500, Bryan Drewery wrote: > > > On 9/23/2014 1:20 PM, Konstantin Belousov wrote: > > > > On Tue, Sep 23, 2014 at 05:04:21PM +0000, Bryan Drewery wrote: > > > >> Author: bdrewery > > > >> Date: Tue Sep 23 17:04:21 2014 > > > >> New Revision: 272032 > > > >> URL: http://svnweb.freebsd.org/changeset/base/272032 > > > >> > > > >> Log: > > > >> DEBUG_LOCKS no longer modifies 'struct vnode', nor does fstat(1) use > > > >> it. > > > >> fstat(1) now uses libprocstat(9). There is no userland impact to > > > >> using this.> > > > > > DEBUG_VFS_LOCKS does modify KBI of VFS, by adding struct stack to > > > > lockmgr, and lockmgr is embedded into each struct vnode. > > > > > > > > VFS modules, in particular, filesystems, compiled for mismatched > > > > kernel WRT DEBUG_VFS_LOCKS, would cause strange breakage. > > > > > > Well, perhaps the comment needs to be updated to state that > > > DEBUG_VFS_LOCKS modifies VFS KBI so any VFS modules will need to > > > recompiled. > > > > > > I did see the stack was moved to lockmgr, but given the use of > > > libprocstat, and lockmgr being a kernel struct, I don't think it's worth > > > mentioning userland here. > > > > > > Sound good? > > > > I agree, I do not think that userland is affected. > > It is for at least lsof (which does not use libprocstat and cannot easily be > adopted to use it exclusively as it pulls a lot more data out than libprocstat > exports such as the info about file locks, etc.) We cannot seriously consider the lsof as application which uses stable interfaces. I.e., binary incompatibility for lsof even on the stable branch or on -pX is not an issue. Lsof verifies kernel release name and warns if it differs from the one used at the compilation time, rightfully.