From: Steven Rostedt <rostedt@goodmis.org>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: ksummit <ksummit-discuss@lists.linuxfoundation.org>
Subject: Re: [Ksummit-discuss] [TECH TOPIC] Getting better/supplementary error info back to userspace
Date: Wed, 19 Jul 2017 09:02:39 -0400 [thread overview]
Message-ID: <20170719090239.39f031c5@gandalf.local.home> (raw)
In-Reply-To: <CA+55aFySG7NAvsphb76J-M2YuM8_4wQ8Cvufu24Gb=EhpaoKTg@mail.gmail.com>
On Wed, 12 Jul 2017 09:19:55 -0700
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Wed, Jul 12, 2017 at 8:21 AM, Stephen Hemminger
> <stephen@networkplumber.org> wrote:
> >
> > Netlink has recently got extended error reporting, still not used widely
> > and library support is lacking in most places.
>
> Yeah, and that "not widely supported and library support is lacking"
> is always going to be an issue with anything like that.
>
> Along with internationalization, which is a whole nasty set of issues
> in itself with error messages.
>
> It's not going to happen, in other words. The problems are basically
> insurmountable, and the thing it fixes will always be some special
> case that doesn't much matter.
>
> Every time it comes up it is because some developer found one case
> that they were hunting down and it annoyed them, and the developer
> went "if only it had included more information and it would have been
> obvious".
>
> But every time it comes up people ignore this basic issue:
>
> [torvalds@i7 linux]$ git grep -e '-E[A-Z]\{4\}' | wc -l
> 182523
>
Note a lot of those -E* are not going to user space. Some are in
comments, and some are used internally. I use them to pass back
information to other kernel only routines, as some errors are more
critical than others.
>
> Give it up. It's really is a horrible idea for so many reasons.
>
One reason that this has never taken off is that there is no good
infrastructure in doing it. I wouldn't tell people to give it up, but
I don't see a one size fits all. In tracing, we have ways to pass
detailed errors back to user space. But that's probably one of the
easier cases as we have defined methods to do so.
A more generic approach would require a lot more planning, and making
it simple to use both in user space and in the kernel. If it is too
complex in either place, it will be ignored.
-- Steve
next prev parent reply other threads:[~2017-07-19 13:02 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-12 12:43 David Howells
2017-07-12 14:33 ` Arnaldo Carvalho de Melo
2017-07-12 14:44 ` Arnaldo Carvalho de Melo
2017-07-12 14:57 ` David Howells
2017-07-12 15:21 ` Stephen Hemminger
2017-07-12 16:19 ` Linus Torvalds
2017-07-12 16:35 ` Stephen Hemminger
2017-07-19 13:02 ` Steven Rostedt [this message]
2017-07-24 7:55 ` Miklos Szeredi
2017-07-24 8:25 ` David Howells
2017-07-21 13:41 ` David Howells
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=20170719090239.39f031c5@gandalf.local.home \
--to=rostedt@goodmis.org \
--cc=ksummit-discuss@lists.linuxfoundation.org \
--cc=torvalds@linux-foundation.org \
/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