All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: Christoph Hellwig <hch@infradead.org>,
	Mike Snitzer <snitzer@kernel.org>,
	dm-devel@redhat.com, linux-block@vger.kernel.org,
	Alasdair G Kergon <agk@redhat.com>,
	Genjian Zhang <zhanggenjian@kylinos.cn>,
	Jiangshan Yi <yijiangshan@kylinos.cn>,
	Jilin Yuan <yuanjilin@cdjrlc.com>,
	Milan Broz <gmazyland@gmail.com>,
	Nathan Huckleberry <nhuck@google.com>,
	Nikos Tsironis <ntsironis@arrikto.com>,
	Shaomin Deng <dengshaomin@cdjrlc.com>
Subject: Re: [git pull] device mapper changes for 6.1
Date: Tue, 18 Oct 2022 15:17:02 -0700	[thread overview]
Message-ID: <CAHk-=wjTgPg3H=2BPtTdHdM5=4wvEA3YCaDEm4P6TQnjvw-CEA@mail.gmail.com> (raw)
In-Reply-To: <alpine.LRH.2.02.2210181515170.23349@file01.intranet.prod.int.rdu2.redhat.com>

On Tue, Oct 18, 2022 at 1:29 PM Mikulas Patocka <mpatocka@redhat.com> wrote:
>
> The error string is not intended to be parsed by userspace (I agree that
> parsing the error string is a horrible idea, but this is not going to
> happen).

I am happy we agree on that fundamental issue.

But it's also why error strings are a HORRIBLE HORRIBLE idea.

They are literally worse than just plain 'errno', exactly because user
space MUST NOT parse them.

They are worse because:

 - user space will parse them anyway, for localization reasons, so the
whole design is garbage

 - user space that correctly doesn't parse them cannot use them for
any helpful thing apart from just displaying them, which makes them
actively worse than having a number that you *can* make actual
decision on.

In other words, user space either can violate the fundamental rule of
"don't parse it", or they are actively weaker than then errno numbers
we already have.

Either way, they are worse. See?

>  It is intended to be displayed to the user by tools such as
> cryptsetup or integritysetup. The tool can't read the log, extract
> messages from it and display them.

Bullshit.

The tools could just use the error number and together with the
operation that failed, make a very good assumption on what went wrong.

And even when that assumption isn't some 100% "this is the reason",
the tool can easily print out helpful hints, like "This is often
because of Xyz".

And guess what? With an errno, the tool can do this MUCH BETTER.

It can localize the error messages.

It can do different things for different error messages.

And it will work with old kernels too.

> With "just use errno", the user sees messages like "device-mapper: reload
> ioctl on test (254:0) failed: No such file or directory" and it's not much
> useful because it doesn't tell what went wrong.

Again, I call bullshit.

You are saying "the tools isn't helpful, so let's change the kernel interface".

And that's just plain stupid.

if the tool isn't helpful, then FIX THE TOOL.

It's that simple.

The fact is, dm isn't special. We use 'errno' absolutely everywhere
else. What makes dm so special that the dm tools can't deal well with
them?

Look at the profile tools (just to give an example of a tool that is
in the kernel tree, so i can grep for it). Sometimes it does just

                if (aio_errno != EINTR)
                        pr_err("failed to write perf data, error: %m\n");

and prints that error string. But sometimes it does things like

                if (errno == EPERM) {
                        pr_err("Permission error mapping pages.\n"
                               "Consider increasing "
                               "/proc/sys/kernel/perf_event_mlock_kb,\n"
                               "or try again with a smaller value of
-m/--mmap_pages.\n"
                               "(current value: %u,%u)\n",
                               opts->mmap_pages, opts->auxtrace_mmap_pages);

because the tool isn't garbage.

You are basically saying that the kernel should generate those strings.

And I'm saying you are completely wrong, and that no, I will not pull
this kind of silly interface, because it's an actively horribly broken
garbage interface.

Furthermore, I'm telling you that you need to really *understand* that
no, device-mapper isn't some super-special thing that magically should
do string errors.

This is not something worth discussing. This is something where you
need to just realize that you are wrong.

End of story.

                  Linus

WARNING: multiple messages have this Message-ID (diff)
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Mikulas Patocka <mpatocka@redhat.com>
Cc: linux-block@vger.kernel.org, Jilin Yuan <yuanjilin@cdjrlc.com>,
	Nikos Tsironis <ntsironis@arrikto.com>,
	Shaomin Deng <dengshaomin@cdjrlc.com>,
	Mike Snitzer <snitzer@kernel.org>,
	Nathan Huckleberry <nhuck@google.com>,
	Christoph Hellwig <hch@infradead.org>,
	dm-devel@redhat.com, Genjian Zhang <zhanggenjian@kylinos.cn>,
	Milan Broz <gmazyland@gmail.com>,
	Alasdair G Kergon <agk@redhat.com>,
	Jiangshan Yi <yijiangshan@kylinos.cn>
Subject: Re: [dm-devel] [git pull] device mapper changes for 6.1
Date: Tue, 18 Oct 2022 15:17:02 -0700	[thread overview]
Message-ID: <CAHk-=wjTgPg3H=2BPtTdHdM5=4wvEA3YCaDEm4P6TQnjvw-CEA@mail.gmail.com> (raw)
In-Reply-To: <alpine.LRH.2.02.2210181515170.23349@file01.intranet.prod.int.rdu2.redhat.com>

On Tue, Oct 18, 2022 at 1:29 PM Mikulas Patocka <mpatocka@redhat.com> wrote:
>
> The error string is not intended to be parsed by userspace (I agree that
> parsing the error string is a horrible idea, but this is not going to
> happen).

I am happy we agree on that fundamental issue.

But it's also why error strings are a HORRIBLE HORRIBLE idea.

They are literally worse than just plain 'errno', exactly because user
space MUST NOT parse them.

They are worse because:

 - user space will parse them anyway, for localization reasons, so the
whole design is garbage

 - user space that correctly doesn't parse them cannot use them for
any helpful thing apart from just displaying them, which makes them
actively worse than having a number that you *can* make actual
decision on.

In other words, user space either can violate the fundamental rule of
"don't parse it", or they are actively weaker than then errno numbers
we already have.

Either way, they are worse. See?

>  It is intended to be displayed to the user by tools such as
> cryptsetup or integritysetup. The tool can't read the log, extract
> messages from it and display them.

Bullshit.

The tools could just use the error number and together with the
operation that failed, make a very good assumption on what went wrong.

And even when that assumption isn't some 100% "this is the reason",
the tool can easily print out helpful hints, like "This is often
because of Xyz".

And guess what? With an errno, the tool can do this MUCH BETTER.

It can localize the error messages.

It can do different things for different error messages.

And it will work with old kernels too.

> With "just use errno", the user sees messages like "device-mapper: reload
> ioctl on test (254:0) failed: No such file or directory" and it's not much
> useful because it doesn't tell what went wrong.

Again, I call bullshit.

You are saying "the tools isn't helpful, so let's change the kernel interface".

And that's just plain stupid.

if the tool isn't helpful, then FIX THE TOOL.

It's that simple.

The fact is, dm isn't special. We use 'errno' absolutely everywhere
else. What makes dm so special that the dm tools can't deal well with
them?

Look at the profile tools (just to give an example of a tool that is
in the kernel tree, so i can grep for it). Sometimes it does just

                if (aio_errno != EINTR)
                        pr_err("failed to write perf data, error: %m\n");

and prints that error string. But sometimes it does things like

                if (errno == EPERM) {
                        pr_err("Permission error mapping pages.\n"
                               "Consider increasing "
                               "/proc/sys/kernel/perf_event_mlock_kb,\n"
                               "or try again with a smaller value of
-m/--mmap_pages.\n"
                               "(current value: %u,%u)\n",
                               opts->mmap_pages, opts->auxtrace_mmap_pages);

because the tool isn't garbage.

You are basically saying that the kernel should generate those strings.

And I'm saying you are completely wrong, and that no, I will not pull
this kind of silly interface, because it's an actively horribly broken
garbage interface.

Furthermore, I'm telling you that you need to really *understand* that
no, device-mapper isn't some super-special thing that magically should
do string errors.

This is not something worth discussing. This is something where you
need to just realize that you are wrong.

End of story.

                  Linus

--
dm-devel mailing list
dm-devel@redhat.com
https://listman.redhat.com/mailman/listinfo/dm-devel


  reply	other threads:[~2022-10-18 22:17 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-10-18 16:20 [git pull] device mapper changes for 6.1 Mike Snitzer
2022-10-18 16:20 ` [dm-devel] " Mike Snitzer
2022-10-18 18:17 ` Christoph Hellwig
2022-10-18 18:17   ` [dm-devel] " Christoph Hellwig
2022-10-18 18:48   ` Mike Snitzer
2022-10-18 18:48     ` [dm-devel] " Mike Snitzer
2022-10-20  8:16     ` Christoph Hellwig
2022-10-20  8:16       ` Christoph Hellwig
2022-10-20 11:44       ` Mikulas Patocka
2022-10-20 11:44         ` Mikulas Patocka
2022-10-18 18:54   ` Linus Torvalds
2022-10-18 18:54     ` [dm-devel] " Linus Torvalds
2022-10-18 19:19     ` Linus Torvalds
2022-10-18 19:19       ` [dm-devel] " Linus Torvalds
2022-10-18 21:13       ` Mike Snitzer
2022-10-18 21:13         ` [dm-devel] " Mike Snitzer
2022-10-18 22:11         ` Milan Broz
2022-10-18 22:11           ` [dm-devel] " Milan Broz
2022-10-18 22:18           ` Linus Torvalds
2022-10-18 22:18             ` [dm-devel] " Linus Torvalds
2022-10-18 20:28     ` Mikulas Patocka
2022-10-18 20:28       ` [dm-devel] " Mikulas Patocka
2022-10-18 22:17       ` Linus Torvalds [this message]
2022-10-18 22:17         ` Linus Torvalds
2022-10-19  6:18     ` Jason A. Donenfeld
2022-10-19  6:18       ` [dm-devel] " Jason A. Donenfeld
2022-10-20  8:17     ` Christoph Hellwig
2022-10-20  8:17       ` Christoph Hellwig

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='CAHk-=wjTgPg3H=2BPtTdHdM5=4wvEA3YCaDEm4P6TQnjvw-CEA@mail.gmail.com' \
    --to=torvalds@linux-foundation.org \
    --cc=agk@redhat.com \
    --cc=dengshaomin@cdjrlc.com \
    --cc=dm-devel@redhat.com \
    --cc=gmazyland@gmail.com \
    --cc=hch@infradead.org \
    --cc=linux-block@vger.kernel.org \
    --cc=mpatocka@redhat.com \
    --cc=nhuck@google.com \
    --cc=ntsironis@arrikto.com \
    --cc=snitzer@kernel.org \
    --cc=yijiangshan@kylinos.cn \
    --cc=yuanjilin@cdjrlc.com \
    --cc=zhanggenjian@kylinos.cn \
    /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.