From: "J. Bruce Fields" <bfields@fieldses.org>
To: Davidlohr Bueso <dave@gnu.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Matthew Wilcox <matthew@wil.cx>,
linux-fsdevel <linux-fsdevel@vger.kernel.org>,
lkml <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] locks: export device name
Date: Wed, 15 Feb 2012 07:42:30 -0500 [thread overview]
Message-ID: <20120215124230.GA11393@fieldses.org> (raw)
In-Reply-To: <1329303162.3356.6.camel@offbook>
On Wed, Feb 15, 2012 at 11:52:42AM +0100, Davidlohr Bueso wrote:
> On Tue, 2012-02-14 at 14:09 -0500, J. Bruce Fields wrote:
> > On Mon, Feb 13, 2012 at 04:34:25PM -0800, Andrew Morton wrote:
> > > I don't get it. This is an immediate and non-back-compatible change to
> > > the format of /proc/locks. The only way this can avoid breaking things
> > > is if there are no programs or scripts in use by anyone which use
> > > this field. What am I missing here?
> >
> > I'm a little surprised anything parses that file.
>
> To my knowledge only lslk - but the whole point here is that its going
> to be replaced by lslocks.
>
> >
> > But, yes, looks like I can "yum install" lslk on Fedora 16, as an
> > example. Can't get it to do anything useful, though. Does it actually
> > work on any recent distro?
>
> It works on Ubuntu's latest release.
OK, in that case I'm with Andrew, we'd need to do this more carefully.
People should be able to use something like a recent Ubuntu release to
test more recent kernels, and we don't want their tools to break when we
do that.
> > Perhaps safest would be to replace /proc/locks by another interface and
> > deprecate this one.
>
> If exporting the name in the current /proc/locks file is out of the
> question, then IMHO I don't think it would be worth adding a new
> interface just for such a small change.
OK.
If you want to just change this over, I guess the thing to do would be
to stick something in feature-removal-schedule.txt saying "we'll switch
this in 2 years" (or however long you think before there are
realistically no more lslk users left), then do it then.
Switching to a new api would be better as we could warn users of the old
api then. Maybe it'd be worth it if there was some other change we'd
been wanting to make? Can't think of anything off the top of my head.
We may be adding more lock types--will lslk and lslocks handle that
gracefully?
--b.
next prev parent reply other threads:[~2012-02-15 12:42 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-02-10 21:06 [PATCH] locks: export device name Davidlohr Bueso
2012-02-14 0:34 ` Andrew Morton
2012-02-14 19:09 ` J. Bruce Fields
2012-02-15 10:52 ` Davidlohr Bueso
2012-02-15 12:42 ` J. Bruce Fields [this message]
2012-02-15 20:39 ` Andrew Morton
2012-02-16 22:37 ` Davidlohr Bueso
2012-02-16 22:59 ` Andrew Morton
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120215124230.GA11393@fieldses.org \
--to=bfields@fieldses.org \
--cc=akpm@linux-foundation.org \
--cc=dave@gnu.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=matthew@wil.cx \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox