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@xxxxxxxxxx> 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
