All of lore.kernel.org
 help / color / mirror / Atom feed
From: Stefani Seibold <stefani@seibold.net>
To: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Cc: Yuanhan Liu <yliu.null@gmail.com>,
	linux-kernel@vger.kernel.org,
	Andrew Morton <akpm@linux-foundation.org>,
	Wei Yang <weiyang@linux.vnet.ibm.com>,
	Fengguang Wu <fengguang.wu@intel.com>,
	Stephen Rothwell <sfr@canb.auug.org.au>
Subject: Re: [PATCH] kfifo: remove unnecessary type check
Date: Fri, 26 Oct 2012 11:26:31 +0200	[thread overview]
Message-ID: <1351243591.8719.2.camel@wall-e> (raw)
In-Reply-To: <20121026071757.GB2778@yliu-dev.sh.intel.com>

Am Freitag, den 26.10.2012, 15:17 +0800 schrieb Yuanhan Liu:
> On Fri, Oct 26, 2012 at 08:51:06AM +0200, Stefani Seibold wrote:
> > Am Freitag, den 26.10.2012, 14:11 +0800 schrieb Yuanhan Liu:
> > > On Fri, Oct 26, 2012 at 07:38:31AM +0200, Stefani Seibold wrote:
> > > > Am Freitag, den 26.10.2012, 09:46 +0800 schrieb Yuanhan Liu:
> > > > > From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
> > > > > 
> > > > > Firstly, this kind of type check doesn't work. It does something similay
> > > > > like following:
> > > > > 	void * __dummy = NULL;
> > > > > 	__buf = __dummy;
> > > > > 
> > > > > __dummy is defined as void *. Thus it will not trigger warnings as
> > > > > expected.
> > > > > 
> > > > > Second, we don't need that kind of check. Since the prototype
> > > > > of __kfifo_out is:
> > > > > 	unsigned int __kfifo_out(struct __kfifo *fifo,  void *buf, unsigned int len)
> > > > > 
> > > > > buf is defined as void *, so we don't need do the type check. Remove it.
> > > > > 
> > > > > LINK: https://lkml.org/lkml/2012/10/25/386
> > > > > LINK: https://lkml.org/lkml/2012/10/25/584
> > > > > 
> > > > > Cc: Andrew Morton <akpm@linux-foundation.org>
> > > > > Cc: Wei Yang <weiyang@linux.vnet.ibm.com>
> > > > > Cc: Stefani Seibold <stefani@seibold.net>
> > > > > Cc: Fengguang Wu <fengguang.wu@intel.com>
> > > > > Cc: Stephen Rothwell <sfr@canb.auug.org.au>
> > > > > Signed-off-by: Yuanhan Liu <yuanhan.liu@linux.intel.com>
> > > > > ---
> > 
> > > > 
> > > > Did you tried to compile the whole kernel including all the drivers with
> > > > your patch?
> > > 
> > > Hi Stefani,
> > > 
> > > I did a build test, it did't introduce any new compile errors and
> > > warnings. While, I haven't tried make allmodconfig then. Does this patch
> > > seems wrong to you?
> > > 
> > > Thanks,
> > > Yuanhan Liu
> > 
> > Hi Liu,
> > 
> > no the patch seems not wrong to me. But as you see with the previous
> > patch it is not easy to predict the side effects.
> > 
> > An allmodconfig together with C=2 is necessary to check if there is no
> > side effects which current users of the kfifo API.
> 
> Hi Stefani,
> 
> Make with C=2 will produce tons of warnings, hard to tell it introduces
> new warnings or not. I build some drivers used kfifo and samples as you
> suggested with C=2, find no new warnings. I will build all drivers that
> used kfifo with C=2 later, and will post the result here.
> 

That will be great...

> > 
> > Also you have to build the kfifo samples, since this example code use
> > all features of the kfifo API.
> > 
> > And again: The kfifo is designed to do the many things at compile time,
> > not at runtime. If you modify the code, you have to check the compiler
> > assembler output for no degradation, especially in kfifo_put, kfifo_get,
> > kfifo_in, kfifo_out, __kfifo_in and __kfifo_out. Prevent runtime checks
> > if you can do it at compile time. This is the basic reasons to do it in
> > macros.
> 
> Is it enought to check kernel/kfifo.o only? I build that file with
> and without this patch. And then  dump it by objdump -D kernel/fifo.o to
> /tmp/kfifo.dump.with and /tmp/kfifo.dump.without, respectively. And the
> two dump file are exactly same.
> 

No, since most of the code is inlined due performace reasons, you have
to hack the kfifo examples output code for regressions and code
increase.
 
Greetings,
Stefani



  parent reply	other threads:[~2012-10-26  9:27 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-26  1:46 [PATCH] kfifo: remove unnecessary type check Yuanhan Liu
2012-10-26  5:38 ` Stefani Seibold
2012-10-26  6:11   ` Yuanhan Liu
2012-10-26  6:51     ` Stefani Seibold
2012-10-26  7:17       ` Yuanhan Liu
2012-10-26  7:33         ` Yuanhan Liu
2012-10-26  9:26         ` Stefani Seibold [this message]
2012-10-26 13:04           ` Yuanhan Liu
2012-10-26 13:42             ` Stefani Seibold
2012-10-27  8:43               ` Yuanhan Liu
     [not found]     ` <20121026095244.GA815@richard.(null)>
2012-10-26 12:31       ` Yuanhan Liu
     [not found]         ` <20121027015558.GA3983@richard.(null)>
2012-10-27  8:48           ` Yuanhan Liu

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=1351243591.8719.2.camel@wall-e \
    --to=stefani@seibold.net \
    --cc=akpm@linux-foundation.org \
    --cc=fengguang.wu@intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sfr@canb.auug.org.au \
    --cc=weiyang@linux.vnet.ibm.com \
    --cc=yliu.null@gmail.com \
    --cc=yuanhan.liu@linux.intel.com \
    /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.