All of lore.kernel.org
 help / color / mirror / Atom feed
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: 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>,
	Mikulas Patocka <mpatocka@redhat.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 11:54:49 -0700	[thread overview]
Message-ID: <CAHk-=wg3cpPyoO8u+8Fu1uk86bgTUYanfKhmxMsZzvY_mV=Cxw@mail.gmail.com> (raw)
In-Reply-To: <Y07twbDIVgEnPsFn@infradead.org>

On Tue, Oct 18, 2022 at 11:17 AM Christoph Hellwig <hch@infradead.org> wrote:
>
> On Tue, Oct 18, 2022 at 12:20:50PM -0400, Mike Snitzer wrote:
> >
> > - Enhance DM ioctl interface to allow returning an error string to
> >   userspace. Depends on exporting is_vmalloc_or_module_addr() to allow
> >   DM core to conditionally free memory allocated with kasprintf().
>
> That really does not sound like a good idea at all.  And it does not
> seem to have any MM or core maintainer signoffs.

I wouldn't worry about maintainer sign-offs just for exporting a
helper function, but I agree with the whole concept being a complete
disaster and not a good idea at all.

Use errno.

It really is that simple. Strings have been discussed before, and they
are simply not a good idea. If your interface is so complicated that
you think errors need some textual explanation, your interface is
probably garbage.

Strings also have allocation issues (as you found out), and have
serious localization issues.

Yes, we do a lot of strings in the kernel in the form of dmesg, and we
have the rule that we simply don't localize. But that's dmesg. It's
for special stuff, not some interface.

And equally importantly, some really small detail in the kernel really
has *NO* business making up new error models of its own. You may think
that the DM ioctl's are a big and important deal, but realistically,
it's just an odd corner of the world that very very few people care
about, and they can use the same error numbers that EVERYBODY ELSE HAS
BEEN USING FOR SIX DECADES!

Don't reinvent something that works - badly.

I think we have one major interface that is string-based (apart from
the obvious pathname ones and the strings passed to 'execve()').

It's 'mount()' (and now fsconfig() etc), and it's string-based mainly
because it has that nasty "arbitrary things that different filesystem
may need for configuration"). And it has some nasty logging model
associated with it too for output.

But no, we absolutely do *not* want to emulate that particular horror
anywhere else.

If you think some errors are really important and hard to understand,
maybe you can just log them with a ratelimited pr_info() or something.

           Linus

WARNING: multiple messages have this Message-ID (diff)
From: Linus Torvalds <torvalds@linux-foundation.org>
To: Christoph Hellwig <hch@infradead.org>
Cc: 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>,
	linux-block@vger.kernel.org, dm-devel@redhat.com,
	Mikulas Patocka <mpatocka@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 11:54:49 -0700	[thread overview]
Message-ID: <CAHk-=wg3cpPyoO8u+8Fu1uk86bgTUYanfKhmxMsZzvY_mV=Cxw@mail.gmail.com> (raw)
In-Reply-To: <Y07twbDIVgEnPsFn@infradead.org>

On Tue, Oct 18, 2022 at 11:17 AM Christoph Hellwig <hch@infradead.org> wrote:
>
> On Tue, Oct 18, 2022 at 12:20:50PM -0400, Mike Snitzer wrote:
> >
> > - Enhance DM ioctl interface to allow returning an error string to
> >   userspace. Depends on exporting is_vmalloc_or_module_addr() to allow
> >   DM core to conditionally free memory allocated with kasprintf().
>
> That really does not sound like a good idea at all.  And it does not
> seem to have any MM or core maintainer signoffs.

I wouldn't worry about maintainer sign-offs just for exporting a
helper function, but I agree with the whole concept being a complete
disaster and not a good idea at all.

Use errno.

It really is that simple. Strings have been discussed before, and they
are simply not a good idea. If your interface is so complicated that
you think errors need some textual explanation, your interface is
probably garbage.

Strings also have allocation issues (as you found out), and have
serious localization issues.

Yes, we do a lot of strings in the kernel in the form of dmesg, and we
have the rule that we simply don't localize. But that's dmesg. It's
for special stuff, not some interface.

And equally importantly, some really small detail in the kernel really
has *NO* business making up new error models of its own. You may think
that the DM ioctl's are a big and important deal, but realistically,
it's just an odd corner of the world that very very few people care
about, and they can use the same error numbers that EVERYBODY ELSE HAS
BEEN USING FOR SIX DECADES!

Don't reinvent something that works - badly.

I think we have one major interface that is string-based (apart from
the obvious pathname ones and the strings passed to 'execve()').

It's 'mount()' (and now fsconfig() etc), and it's string-based mainly
because it has that nasty "arbitrary things that different filesystem
may need for configuration"). And it has some nasty logging model
associated with it too for output.

But no, we absolutely do *not* want to emulate that particular horror
anywhere else.

If you think some errors are really important and hard to understand,
maybe you can just log them with a ratelimited pr_info() or something.

           Linus

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


  parent reply	other threads:[~2022-10-18 18:55 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 [this message]
2022-10-18 18:54     ` 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
2022-10-18 22:17         ` [dm-devel] " 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-=wg3cpPyoO8u+8Fu1uk86bgTUYanfKhmxMsZzvY_mV=Cxw@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.