From: Alexander Potapenko <glider@google.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: LKML <linux-kernel@vger.kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Andrey Konovalov <andreyknvl@google.com>,
Dmitriy Vyukov <dvyukov@google.com>,
Ingo Molnar <mingo@redhat.com>, Marco Elver <elver@google.com>,
Petr Mladek <pmladek@suse.com>,
Steven Rostedt <rostedt@goodmis.org>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Linux Memory Management List <linux-mm@kvack.org>
Subject: Re: [PATCH v2 3/5] docs: ABI: add /sys/kernel/error_report/ documentation
Date: Fri, 15 Jan 2021 16:26:21 +0100 [thread overview]
Message-ID: <CAG_fn=Xen6Nd9qJnW6F4r5vgj7WAUo40BHeN_FXKpJ2jrpT6-g@mail.gmail.com> (raw)
In-Reply-To: <YAGckOeJxqCcHKa+@kroah.com>
> sysfs is "one value per file"
What about existing interfaces that even export binary blobs through
sysfs (e.g. /sys/firmware, /sys/boot_params)?
What qualifies as a "value" in that case?
> please put something like this in
> tracefs, as there is no such rules there. Or debugfs, but please, not
> sysfs.
Does tracefs have anything similar to sysfs_notify() or any other way
to implement a poll() handler?
Our main goal is to let users wait on poll(), so that they don't have
to check the file for new contents every now and then. Is it possible
with tracefs or debugfs?
Also, for our goal debugfs isn't a particularly good fit, as Android
kernels do not enable debugfs.
Not sure about tracefs, they seem to have it, need to check.
Do you think it is viable to keep
/sys/kernel/error_report/report_count in sysfs and use it for
notifications, but move last_report somewhere else?
(I'd probably prefer procfs, but it could be tracefs as well, if you
find that better).
This way it will still be possible to easily notify userspace about
new reports, but the report itself won't have any atomicity
guarantees. Users will have to check the report count to ensure it
didn't change under their feet.
> Also, any reason you didn't cc: the sysfs maintainers?
Only my lack of common sense :)
I'll add them should the following patches rely on sysfs, thank you!
Alex
--
Alexander Potapenko
Software Engineer
Google Germany GmbH
Erika-Mann-Straße, 33
80636 München
Geschäftsführer: Paul Manicle, Halimah DeLaine Prado
Registergericht und -nummer: Hamburg, HRB 86891
Sitz der Gesellschaft: Hamburg
next prev parent reply other threads:[~2021-01-15 15:26 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-15 13:03 [PATCH v2 0/5] Add sysfs interface to collect reports from debugging tools Alexander Potapenko
2021-01-15 13:03 ` [PATCH v2 1/5] tracing: add error_report trace points Alexander Potapenko
2021-01-15 13:03 ` [PATCH v2 2/5] lib: add error_report_notify to collect debugging tools' reports Alexander Potapenko
2021-01-15 13:50 ` Greg KH
2021-01-15 17:17 ` Alexander Potapenko
2021-01-18 11:38 ` Petr Mladek
2021-01-18 13:08 ` Alexander Potapenko
2021-01-18 13:14 ` Alexander Potapenko
2021-01-18 16:43 ` Petr Mladek
2021-01-21 13:13 ` Alexander Potapenko
2021-01-15 13:03 ` [PATCH v2 3/5] docs: ABI: add /sys/kernel/error_report/ documentation Alexander Potapenko
2021-01-15 13:45 ` Greg KH
2021-01-15 15:26 ` Alexander Potapenko [this message]
2021-01-15 15:45 ` Greg KH
2021-01-15 16:52 ` Steven Rostedt
2021-01-18 10:22 ` Alexander Potapenko
2021-01-18 14:52 ` Steven Rostedt
2021-01-15 13:03 ` [PATCH v2 4/5] kfence: use error_report_start and error_report_end tracepoints Alexander Potapenko
2021-01-15 13:03 ` [PATCH v2 5/5] kasan: " Alexander Potapenko
2021-01-15 13:06 ` [PATCH v2 0/5] Add sysfs interface to collect reports from debugging tools Vlastimil Babka
2021-01-15 13:09 ` Alexander Potapenko
2021-01-21 12:56 ` Alexander Potapenko
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='CAG_fn=Xen6Nd9qJnW6F4r5vgj7WAUo40BHeN_FXKpJ2jrpT6-g@mail.gmail.com' \
--to=glider@google.com \
--cc=akpm@linux-foundation.org \
--cc=andreyknvl@google.com \
--cc=dvyukov@google.com \
--cc=elver@google.com \
--cc=gregkh@linuxfoundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=mingo@redhat.com \
--cc=pmladek@suse.com \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox