All of lore.kernel.org
 help / color / mirror / Atom feed
From: shuah <shuah@kernel.org>
To: Brendan Higgins <brendanhiggins@google.com>
Cc: kunit-dev@googlegroups.com, linux-kernel@vger.kernel.org,
	linux-kselftest@vger.kernel.org, frowand.list@gmail.com,
	sboyd@kernel.org, Randy Dunlap <rdunlap@infradead.org>,
	Stephen Rothwell <sfr@canb.auug.org.au>, shuah <shuah@kernel.org>
Subject: Re: [PATCH v1] kunit: fix failure to build without printk
Date: Tue, 27 Aug 2019 14:21:39 -0600	[thread overview]
Message-ID: <ae9b9102-187c-eefe-d377-6efa63de2d28@kernel.org> (raw)
In-Reply-To: <20190827174932.44177-1-brendanhiggins@google.com>

On 8/27/19 11:49 AM, Brendan Higgins wrote:
> Previously KUnit assumed that printk would always be present, which is
> not a valid assumption to make. Fix that by ifdefing out functions which
> directly depend on printk core functions similar to what dev_printk
> does.
> 
> Reported-by: Randy Dunlap <rdunlap@infradead.org>
> Link: https://lore.kernel.org/linux-kselftest/0352fae9-564f-4a97-715a-fabe016259df@kernel.org/T/#t
> Cc: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Brendan Higgins <brendanhiggins@google.com>
> ---
>   include/kunit/test.h |  7 +++++++
>   kunit/test.c         | 41 ++++++++++++++++++++++++-----------------
>   2 files changed, 31 insertions(+), 17 deletions(-)
> 
> diff --git a/include/kunit/test.h b/include/kunit/test.h
> index 8b7eb03d4971..339af5f95c4a 100644
> --- a/include/kunit/test.h
> +++ b/include/kunit/test.h
> @@ -339,9 +339,16 @@ static inline void *kunit_kzalloc(struct kunit *test, size_t size, gfp_t gfp)
>   
>   void kunit_cleanup(struct kunit *test);
>   
> +#ifdef CONFIG_PRINTK

Please make this #if defined(CONFIG_PRINTK)

>   void __printf(3, 4) kunit_printk(const char *level,

Line these two up with const char *level,

>   				 const struct kunit *test,
>   				 const char *fmt, ...);
> +#else
> +static inline void __printf(3, 4) kunit_printk(const char *level,
> +					       const struct kunit *test,
> +					       const char *fmt, ...)

Same here.

> +{}

Either line this up or make it

const char *fmt, ...) { }

It is hard to read the way it is currently indented.

> +#endif
>   
>   /**
>    * kunit_info() - Prints an INFO level message associated with @test.
> diff --git a/kunit/test.c b/kunit/test.c
> index b2ca9b94c353..0aa1caf07a6b 100644
> --- a/kunit/test.c
> +++ b/kunit/test.c
> @@ -16,6 +16,7 @@ static void kunit_set_failure(struct kunit *test)
>   	WRITE_ONCE(test->success, false);
>   }
>   
> +#ifdef CONFIG_PRINTK

Same here - if defined

>   static int kunit_vprintk_emit(int level, const char *fmt, va_list args)
>   {
>   	return vprintk_emit(0, level, NULL, 0, fmt, args);
> @@ -40,6 +41,29 @@ static void kunit_vprintk(const struct kunit *test,
>   	kunit_printk_emit(level[1] - '0', "\t# %s: %pV", test->name, vaf);
>   }
>   
> +void kunit_printk(const char *level,
> +		  const struct kunit *test,
> +		  const char *fmt, ...)

Line the arguments up.

> +{
> +	struct va_format vaf;
> +	va_list args;
> +
> +	va_start(args, fmt);
> +
> +	vaf.fmt = fmt;
> +	vaf.va = &args;
> +
> +	kunit_vprintk(test, level, &vaf);
> +
> +	va_end(args);
> +}
> +#else /* CONFIG_PRINTK */
> +static inline int kunit_printk_emit(int level, const char *fmt, ...)
> +{
> +	return 0;

Is there a reason to not use
> +} > +#endif /* CONFIG_PRINTK */
> +
>   static void kunit_print_tap_version(void)
>   {
>   	static bool kunit_has_printed_tap_version;
> @@ -504,20 +528,3 @@ void kunit_cleanup(struct kunit *test)
>   		kunit_resource_free(test, resource);
>   	}
>   }
> -
> -void kunit_printk(const char *level,
> -		  const struct kunit *test,
> -		  const char *fmt, ...) > -{
> -	struct va_format vaf;
> -	va_list args;
> -
> -	va_start(args, fmt);
> -
> -	vaf.fmt = fmt;
> -	vaf.va = &args;
> -
> -	kunit_vprintk(test, level, &vaf);
> -
> -	va_end(args);
> -}
> 

Okay after reviewing this, I am not sure why you need to do all
this.

Why can't you just change the root function that throws the warn:

  static int kunit_vprintk_emit(int level, const char *fmt, va_list args)
{
         return vprintk_emit(0, level, NULL, 0, fmt, args);
}

You aren'r really doing anything extra here, other than calling
vprintk_emit()

Unless I am missing something, can't you solve this problem by including
printk.h and let it handle the !CONFIG_PRINTK case?

thanks,
-- Shuah


  parent reply	other threads:[~2019-08-27 20:21 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-08-27 17:49 [PATCH v1] kunit: fix failure to build without printk Brendan Higgins
2019-08-27 18:58 ` Randy Dunlap
2019-08-27 20:21 ` shuah [this message]
2019-08-27 20:53   ` Randy Dunlap
2019-08-27 21:16     ` shuah
2019-08-27 21:03   ` Brendan Higgins
2019-08-27 21:09     ` Brendan Higgins
2019-08-27 21:36       ` Brendan Higgins
2019-08-27 22:00         ` shuah
2019-08-27 22:16           ` Brendan Higgins
2019-08-27 22:37             ` Tim.Bird
2019-08-27 22:51               ` Brendan Higgins
2019-08-27 22:55             ` shuah
2019-08-27 23:11               ` Brendan Higgins
2019-08-27 21:46 ` Stephen Boyd
2019-08-27 21:51   ` Brendan Higgins

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=ae9b9102-187c-eefe-d377-6efa63de2d28@kernel.org \
    --to=shuah@kernel.org \
    --cc=brendanhiggins@google.com \
    --cc=frowand.list@gmail.com \
    --cc=kunit-dev@googlegroups.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=rdunlap@infradead.org \
    --cc=sboyd@kernel.org \
    --cc=sfr@canb.auug.org.au \
    /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.