All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dave Chinner <david@fromorbit.com>
To: Eric Sandeen <sandeen@sandeen.net>, xfs@oss.sgi.com
Subject: Re: [PATCH] xfs: Document error handling behavior
Date: Thu, 21 Jul 2016 08:25:12 +1000	[thread overview]
Message-ID: <20160720222512.GM16044@dastard> (raw)
In-Reply-To: <20160720090406.GA3094@redhat.com>

On Wed, Jul 20, 2016 at 11:04:06AM +0200, Carlos Maiolino wrote:
> On Tue, Jul 19, 2016 at 11:18:01PM -0700, Eric Sandeen wrote:
> > 
> > 
> > On 7/19/16 2:15 PM, Eric Sandeen wrote:
> > > On 7/19/16 3:04 AM, Carlos Maiolino wrote:
> > >> This is the first try to document the implementation of error handlers into
> > >> sysfs.
> > >>
> > >> Reviews and comments are appreciated, please also notice I'm not english-native,
> > >> so, spelling corrections are also appreciated :)
> > > 
> > > Thanks for doing this! 
> > > 
> > > There seems to be a specific sysfs documentation format, see for example
> > > Documentation/ABI/testing/sysfs-fs-ext4 
> > > 
> > > It might be better to follow that format, and refer to it after a brief
> > > explanation of the functionality in the xfs.txt file?
> > 
> > Or not; Dave doesn't like this location, so perhaps best not to take
> > my suggestion.  ;)
> 
> Oh, I can see now why he doesn't like that, I've never seen such directory until
> you mentioned it, why should it be so hidden, and why should we split filesystem
> information into different locations.
> 
> IMHO, if someone want to take a look into filesystem documentation, the person
> goes directly to Documentation/filesystems, I honestly think splitting
> information into two different directories are wrong, and, even though you point
> to there in some other place, it is still bad, sounds like a RPG book... Start
> here...now go to page X...now go to page Y...now go to page Z.
> 
> I can re-format the documentation to the same format from sysfs-fs-ext4, but I
> believe keeping it under Documentation/filesystems is still the best to do. To
> be honest, I actually think we should create an XFS directory under it and put
> everything xfs related there.

I'd just add it to Doc/fs/xfs.txt right now, and we can work out
restructuring details later. Especially as we really need this documentation
added to the xfs-documentation repo (along with a "how to use"
guide). It's a similar situation to the libxfs code shared between
kernel and userspace, I think...

Cheers,

Dave.
-- 
Dave Chinner
david@fromorbit.com

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

  parent reply	other threads:[~2016-07-20 22:25 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-19 10:04 [PATCH] xfs: Document error handling behavior Carlos Maiolino
2016-07-19 21:15 ` Eric Sandeen
2016-07-20  6:18   ` Eric Sandeen
2016-07-20  9:04     ` Carlos Maiolino
2016-07-20 14:00       ` Jan Tulak
2016-07-20 22:25       ` Dave Chinner [this message]
2016-07-22  4:09 ` Zorro Lang
2016-07-22  8:58   ` Carlos Maiolino
2016-08-08 10:57     ` Carlos Eduardo Maiolino
2016-08-08 22:40       ` Dave Chinner
2016-08-09  8:11         ` Carlos Maiolino

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=20160720222512.GM16044@dastard \
    --to=david@fromorbit.com \
    --cc=sandeen@sandeen.net \
    --cc=xfs@oss.sgi.com \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.