From: Andy Shevchenko <andy.shevchenko@gmail.com>
To: Timur Tabi <timur@kernel.org>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
Sergey Senozhatsky <sergey.senozhatsky@gmail.com>,
Petr Mladek <pmladek@suse.com>,
roman.fietze@magna.com, Kees Cook <keescook@chromium.org>,
Steven Rostedt <rostedt@goodmis.org>,
John Ogness <john.ogness@linutronix.de>,
linux-mm <linux-mm@kvack.org>,
Akinobu Mita <akinobu.mita@gmail.com>,
Alexander Viro <viro@zeniv.linux.org.uk>,
Vaibhav Jain <vaibhav@linux.ibm.com>,
Dan Williams <dan.j.williams@intel.com>,
Linux FS Devel <linux-fsdevel@vger.kernel.org>
Subject: Re: [PATCH 1/2] [v2] lib/hexdump: introduce DUMP_PREFIX_UNHASHED for unhashed addresses
Date: Mon, 18 Jan 2021 19:14:11 +0200 [thread overview]
Message-ID: <20210118171411.GG4077@smile.fi.intel.com> (raw)
In-Reply-To: <b39866a4-19cd-879b-1f3e-44126caf9193@kernel.org>
On Mon, Jan 18, 2021 at 09:57:55AM -0600, Timur Tabi wrote:
> On 1/18/21 4:03 AM, Andy Shevchenko wrote:
> > On Sun, Jan 17, 2021 at 12:12 AM Timur Tabi <timur@kernel.org> wrote:
...
> > Any user of this? (For the record, I don't see any other mail except this one)
> It's patch #2 of this set.
I haven't got that one.
> They were all sent together.
Apparently not to me.
> http://lkml.iu.edu/hypermail/linux/kernel/2101.2/00245.html
>
> Let me know what you think.
Makes sense. Hint: use lore.kernel.org references as they are much better in
terms of provided features and patch representation.
...
> > > DUMP_PREFIX_NONE,
> > > DUMP_PREFIX_ADDRESS,
> > > - DUMP_PREFIX_OFFSET
> > > + DUMP_PREFIX_OFFSET,
> > > + DUMP_PREFIX_UNHASHED,
> >
> > Since it's an address, I would like to group them together, i.e. put
> > after DUMP_PREFIX_ADDRESS.
>
> I didn't want to change the numbering of any existing enums, just in case
> there are users that accidentally hard-code the values. I'm trying to make
> this patch as unobtrusive as possible.
But isn't it good to expose those issues (and fix them)?
...
> > Perhaps even add _ADDRESS to DUMP_PREFIX_UNHASHED, but this maybe too
> long.
>
> I think DUMP_PREFIX_ADDRESS_UNHASHED is too long.
What about introducing new two like these:
DUMP_PREFIX_OFFSET,
DUMP_PREFIX_ADDRESS,
DUMP_PREFIX_ADDR_UNHASHED,
DUMP_PREFIX_ADDR_HASHED,
and allow people step-by-step move to them?
--
With Best Regards,
Andy Shevchenko
next prev parent reply other threads:[~2021-01-18 17:15 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-16 22:09 [PATCH 0/2] introduce DUMP_PREFIX_UNHASHED for hex dumps Timur Tabi
2021-01-16 22:09 ` [PATCH 1/2] [v2] lib/hexdump: introduce DUMP_PREFIX_UNHASHED for unhashed addresses Timur Tabi
2021-01-18 10:03 ` Andy Shevchenko
2021-01-18 15:57 ` Timur Tabi
2021-01-18 17:14 ` Andy Shevchenko [this message]
2021-01-18 17:53 ` Timur Tabi
2021-01-16 22:09 ` [PATCH 2/2] mm/page_poison: use unhashed address in hexdump for check_poison_mem() Timur Tabi
2021-01-18 18:26 ` [PATCH 0/2] introduce DUMP_PREFIX_UNHASHED for hex dumps Matthew Wilcox
2021-01-18 19:03 ` Timur Tabi
2021-01-19 0:53 ` Sergey Senozhatsky
2021-01-19 1:47 ` Matthew Wilcox
2021-01-19 10:38 ` Sergey Senozhatsky
2021-01-19 19:45 ` Kees Cook
2021-01-26 16:47 ` Vlastimil Babka
2021-01-26 16:59 ` Timur Tabi
2021-01-26 17:14 ` Steven Rostedt
2021-01-26 17:14 ` Vlastimil Babka
2021-01-26 17:30 ` Timur Tabi
2021-01-26 17:39 ` Steven Rostedt
2021-01-26 17:40 ` Steven Rostedt
2021-01-26 19:23 ` John Ogness
2021-01-27 2:11 ` Sergey Senozhatsky
2021-01-27 3:22 ` Timur Tabi
2021-01-27 10:11 ` Petr Mladek
2021-01-27 10:38 ` Vlastimil Babka
2021-01-19 19:45 ` Kees Cook
2021-01-19 19:55 ` Timur Tabi
2021-01-19 20:10 ` Steven Rostedt
2021-01-19 20:49 ` Timur Tabi
2021-01-19 21:15 ` Steven Rostedt
2021-01-19 21:25 ` Timur Tabi
2021-01-20 9:19 ` Petr Mladek
2021-01-20 12:17 ` Matthew Wilcox
2021-01-20 19:39 ` Linus Torvalds
2021-01-19 20:18 ` Randy Dunlap
2021-01-20 20:28 ` Kees Cook
2021-01-19 2:30 ` Timur Tabi
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=20210118171411.GG4077@smile.fi.intel.com \
--to=andy.shevchenko@gmail.com \
--cc=akinobu.mita@gmail.com \
--cc=akpm@linux-foundation.org \
--cc=dan.j.williams@intel.com \
--cc=john.ogness@linutronix.de \
--cc=keescook@chromium.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=pmladek@suse.com \
--cc=roman.fietze@magna.com \
--cc=rostedt@goodmis.org \
--cc=sergey.senozhatsky@gmail.com \
--cc=timur@kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=vaibhav@linux.ibm.com \
--cc=viro@zeniv.linux.org.uk \
/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.