svn commit: r272032 - head/sys/conf

[John Baldwin]

On Wednesday, September 24, 2014 05:23:39 PM Konstantin Belousov wrote:
> 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.

I don't disagree.  Just noting that it is a commonly-used tool that is 
affected by DEBUG_LOCKS.

-- 
John Baldwin