All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Sterba <dsterba@suse.cz>
To: Omar Sandoval <osandov@osandov.com>
Cc: David Sterba <dsterba@suse.com>, linux-btrfs@vger.kernel.org
Subject: Re: [PATCH] btrfs: sysfs: export dev stats in devinfo directory
Date: Thu, 10 Jun 2021 18:37:01 +0200	[thread overview]
Message-ID: <20210610163700.GC28158@suse.cz> (raw)
In-Reply-To: <YMFi6fSxMUDCU/C9@relinquished.localdomain>

On Wed, Jun 09, 2021 at 05:55:05PM -0700, Omar Sandoval wrote:
> > > The ioctl returns ENODEV is !dev_stats_valid, maybe this file should do
> > > the same? It seems a little awkward to have a flag that means that the
> > > rest of the file is meaningless.
> > 
> > You mean returning -ENODEV when reading the stats file? Or return 0 but
> > the contents is something like 'stats invalid' or similar.
> 
> I'd vote for returning -ENODEV when reading the stats file, but I think
> either one is fine.

Hm so I think this should reflect how the sysfs files are used. They all
contain textual information, and errors are returned when eg. there are
no permissions.

In a shell script it's IMHO more convenient to do

stats=$(cat $devicepath/stats)

and then validate contents of $stats rather then catching the error
value and deciding based on that what happend. Not to say that this
would also print an error message. I've found this in
admin-guide/sysfs-rules.rst that's perhaps closest to a recommendation
we could follow:

172 - When reading and writing sysfs device attribute files, avoid dependency
173     on specific error codes wherever possible. This minimizes coupling to
174     the error handling implementation within the kernel.

So I take it as that error codes belong to the sysfs layer and the
validity of the contents is up to the sysfs user, ie. btrfs in this
case.

  reply	other threads:[~2021-06-10 16:39 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-04 13:20 [PATCH] btrfs: sysfs: export dev stats in devinfo directory David Sterba
2021-06-04 13:23 ` David Sterba
2021-06-04 13:41 ` Anand Jain
2021-06-04 14:21   ` David Sterba
2021-06-04 22:38     ` Anand Jain
2021-06-07 18:55       ` David Sterba
2021-06-09  7:43         ` Anand Jain
2021-06-09 15:14           ` David Sterba
2021-06-04 15:13 ` kernel test robot
2021-06-04 15:13   ` kernel test robot
2021-06-04 16:27 ` kernel test robot
2021-06-04 16:27   ` kernel test robot
2021-06-09 18:24 ` Omar Sandoval
2021-06-09 18:40   ` Omar Sandoval
2021-06-09 18:50   ` David Sterba
2021-06-10  0:55     ` Omar Sandoval
2021-06-10 16:37       ` David Sterba [this message]
2021-06-10 17:54         ` Omar Sandoval

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=20210610163700.GC28158@suse.cz \
    --to=dsterba@suse.cz \
    --cc=dsterba@suse.com \
    --cc=linux-btrfs@vger.kernel.org \
    --cc=osandov@osandov.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.