archive mirror
 help / color / mirror / Atom feed
From: Al Viro <>
To: Jonathan Corbet <>
Cc: Eric Biggers <>,,
	"Tobin C. Harding" <>
Subject: Re: [PATCH 0/4] vfs: update ->get_link() related documentation
Date: Wed, 1 May 2019 03:14:23 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Tue, Apr 30, 2019 at 07:49:43PM -0600, Jonathan Corbet wrote:
> On Wed, 1 May 2019 02:36:49 +0100
> Al Viro <> wrote:
> > Thought I'd replied; apparently not...  Anyway, the problem with those
> > is that there'd been a series of patches converting vfs.txt to new
> > format; I'm not sure what Jon is going to do with it, but these are
> > certain to conflict.  I've no objections to the contents of changes,
> > but if that stuff is getting massive reformatting the first two
> > probably ought to go through Jon's tree.  I can take the last two
> > at any point.
> > 
> > Jon, what's the status of the format conversion?
> Last I saw, it seemed that you wanted changes in how things were done and
> that Tobin (added to CC) had stepped back.  Tobin, are your thoughts on
> the matter different?  I could try to shoehorn them in for 5.2 still, I
> guess, but perhaps the best thing to do is to just take Eric's patch, and
> the reformatting can work around it if need be.

I can certainly apply Eric's series (or ACK it if we end up deciding to
feed it through your tree).

Rereading my replies in that thread, I hadn't been clear back then and
I can see how that could've been created the wrong impression. 

I do have problems with vfs.txt approach in general and I hope we end up
with per object type documents; however, that's completely orthogonal to
format conversion.  IOW, I have no objections whatsoever to format switch
done first; any migration of e.g. dentry-related parts into a separate
document, with lifecycle explicitly documented and descriptions of
methods tied to that can just as well go on top of that.

I don't think that vfs.txt will survive in recognizable form in the long
run, but by all means, let's get the format conversion out of the way
first.  And bits and pieces of contents will survive in the replacement
files when those appear.

  reply	other threads:[~2019-05-01  2:14 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-04-11 23:16 [PATCH 0/4] vfs: update ->get_link() related documentation Eric Biggers
2019-04-11 23:16 ` [PATCH 1/4] Documentation/filesystems/vfs.txt: remove bogus "Last updated" date Eric Biggers
2019-04-11 23:16 ` [PATCH 2/4] Documentation/filesystems/vfs.txt: document how ->i_link works Eric Biggers
2019-04-11 23:16 ` [PATCH 3/4] Documentation/filesystems/Locking: fix ->get_link() prototype Eric Biggers
2019-04-11 23:16 ` [PATCH 4/4] libfs: document simple_get_link() Eric Biggers
2019-04-22 18:03 ` [PATCH 0/4] vfs: update ->get_link() related documentation Eric Biggers
2019-05-01  0:25   ` Eric Biggers
2019-05-01  1:36     ` Al Viro
2019-05-01  1:49       ` Jonathan Corbet
2019-05-01  2:14         ` Al Viro [this message]
2019-05-01  2:17           ` Jonathan Corbet
2019-05-01  4:00             ` Al Viro
2019-05-01  4:15           ` Tobin C. Harding
2019-05-03 12:16             ` Jonathan Corbet

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:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \

* 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;
as well as URLs for NNTP newsgroup(s).