Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Message-ID: <ca01d8c4823c63db52fc0f18d62334aeb5634a50.camel@perches.com>
Subject: Re: [PATCH v2] kunit: fix failure to build without printk
From:   Joe Perches <joe@perches.com>
To:     Tim.Bird@sony.com, brendanhiggins@google.com
Cc:     shuah@kernel.org, sergey.senozhatsky.work@gmail.com,
        kunit-dev@googlegroups.com, linux-kernel@vger.kernel.org,
        linux-kselftest@vger.kernel.org, frowand.list@gmail.com,
        sboyd@kernel.org, pmladek@suse.com, sergey.senozhatsky@gmail.com,
        rostedt@goodmis.org, rdunlap@infradead.org, sfr@canb.auug.org.au
Date:   Fri, 30 Aug 2019 15:46:13 -0700
In-Reply-To: <ECADFF3FD767C149AD96A924E7EA6EAF977A8392@USCULXMSG01.am.sony.com>
References: <20190828093143.163302-1-brendanhiggins@google.com>
         <20190828094929.GA14038@jagdpanzerIV>
         <8b2d63bf-56cd-e8f5-e8ee-2891c2c1be8f@kernel.org>
         <f2d5b474411b2940d62198490f06e77890fbdb32.camel@perches.com>
         <20190830183821.GA30306@google.com>
         <bc688b00b2995e4b11229c3d4d90f532e00792c7.camel@perches.com>
         <ECADFF3FD767C149AD96A924E7EA6EAF977A8392@USCULXMSG01.am.sony.com>
Content-Type: text/plain; charset="ISO-8859-1"
User-Agent: Evolution 3.32.1-2 
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Fri, 2019-08-30 at 21:58 +0000, Tim.Bird@sony.com wrote:
> > From: Joe Perches
[]
> IMHO %pV should be avoided if possible.  Just because people are
> doing it doesn't mean it should be used when it is not necessary.

Well, as the guy that created %pV, I of course
have a different opinion.

> >  then wouldn't it be easier to pass in the
> > > kernel level as a separate parameter and then strip off all printk
> > > headers like this:
> > 
> > Depends on whether or not you care for overall
> > object size.  Consolidated formats with the
> > embedded KERN_<LEVEL> like suggested are smaller
> > overall object size.
> 
> This is an argument I can agree with.  I'm generally in favor of
> things that lessen kernel size creep. :-)

As am I.