Oren Laadan wrote:
>
> Nathan Lynch wrote:
> >
> > Oren Laadan wrote:
> >> Nathan Lynch wrote:
> >>> + pr_debug("%s: unexpected thread_hdr contents: 0x%lx\n",
> >>> + __func__, (unsigned long)thread_hdr->unimplemented);
> >> Given the macro for 'pr_fmt' in include/linux/checkpoint.h, the use of
> >> __func__ is redunant.
> >
> > It seems to me that defining your own pr_fmt in a "public" header like
> > that is inappropriate, or at least unconventional. Any file that
> > happens to include linux/checkpoint.h will have any prior definitions
> > of pr_fmt overridden, no?
> >
>
> Hmmm.. didn't think of it this way. Using the pr_debug() there was yet
> another feedback from LKML, and it seemed reasonable to me. Can you
> think of a case where linux/checkpoint.h will happen to be included
> in checkpoint-related code ?
(Assume you meant "included in checkpoint-unrelated code")
I could see checkpoint.h being included by files that don't
exclusively deal with C/R. If you want a uniform debug statement
format for C/R-related code, that's fine, but this isn't the way to do
it. See the existing users (almost all in drivers/s390).
_______________________________________________
Containers mailing list
Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx
https://lists.linux-foundation.org/mailman/listinfo/containers
