Re: [git pull] device mapper changes for 6.1

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Oct 18, 2022 at 1:29 PM Mikulas Patocka <mpatocka@xxxxxxxxxx> 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@xxxxxxxxxx
https://listman.redhat.com/mailman/listinfo/dm-devel




[Index of Archives]     [DM Crypt]     [Fedora Desktop]     [ATA RAID]     [Fedora Marketing]     [Fedora Packaging]     [Fedora SELinux]     [Yosemite Discussion]     [KDE Users]     [Fedora Docs]

  Powered by Linux