On Thu, Jun 19, 2025 at 03:05:10PM +0530, Anshuman Khandual wrote: > On 18/06/25 11:16 PM, Andy Shevchenko wrote: > > On Wed, Jun 18, 2025 at 09:42:34AM +0530, Anshuman Khandual wrote: > >> Add a new format for printing page table entries. > > > >> Cc: Petr Mladek <pmladek@xxxxxxxx> > >> Cc: Steven Rostedt <rostedt@xxxxxxxxxxx> > >> Cc: Jonathan Corbet <corbet@xxxxxxx> > >> Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> > >> Cc: David Hildenbrand <david@xxxxxxxxxx> > >> Cc: linux-doc@xxxxxxxxxxxxxxx > >> Cc: linux-kernel@xxxxxxxxxxxxxxx > >> Cc: linux-mm@xxxxxxxxx > > > > Please. move these to be after the '---' cutter line below. Just leave SoB tag > > alone. This will have the same effect w/o polluting commit message. > > > >> Signed-off-by: Anshuman Khandual <anshuman.khandual@xxxxxxx> > >> --- > > > > (somewhere here is a good place for all your Cc: tags) > > Is not it better to also capture the Cc: list in the commit message. No it's worse. One may easily get the same from lore. Can you give a good justification for the polluting message with 8 lines over a single line of the useful information, please? > Seems like such has been the practice for various patches on the MM > list. But not sure if that is an expected standard for all patches. It's not an MM subsystem. ... > >> +Print standard page table entry pte_t. > >> + > >> +Passed by reference. > >> + > >> +Examples for a 64 bit page table entry, given &(u64)0xc0ffee:: > > > > What does this mean? > > 64 bit address containing value the 0xc0ffee Please, make it 64-bit address. The example as is is quite confusing. > >> + %ppte 0x00c0ffee > > > > Can it be ever 64-bit? > I am sorry - did not get that. pte_t contained value can be 64 > bits if that's what you meant. Yes, see above why I have such a question. ... > >> + spec.field_width = 10; > >> + spec.precision = 8; > >> + spec.base = 16; > >> + spec.flags = SPECIAL | SMALL | ZEROPAD; > > > > Do not duplicate code we have already in the file. > I am sorry - did not get that. Is the above flag combination some > how wrong ? It's dup. Please, take your time to find the very similar piece of code in one of the helper functions we have. I recommend you to look at the history of the changes in this file for when the new specifier was added and how it is implemented. ... > Could you please kindly elaborate on the code duplication problem > you have mentioned earlier. I might not understand your concern > here correctly. Just find the same or similar pieces of code elsewhere in the same file. Use them. -- With Best Regards, Andy Shevchenko
