From: Thomas Gleixner <tglx@linutronix.de>
To: "Du, Changbin" <changbin.du@intel.com>
Cc: Andrew Morton <akpm@linux-foundation.org>,
Jonathan Corbet <corbet@lwn.net>,
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
"josh@joshtriplett.org" <josh@joshtriplett.org>,
Steven Rostedt <rostedt@goodmis.org>,
Mathieu Desnoyers <mathieu.desnoyers@efficios.com>,
"jiangshanlai@gmail.com" <jiangshanlai@gmail.com>,
John Stultz <john.stultz@linaro.org>, Tejun Heo <tj@kernel.org>,
"borntraeger@de.ibm.com" <borntraeger@de.ibm.com>,
"dchinner@redhat.com" <dchinner@redhat.com>,
"linux-doc@vger.kernel.org" <linux-doc@vger.kernel.org>,
LKML <linux-kernel@vger.kernel.org>
Subject: RE: [PATCH 1/7] debugobjects: make fixup functions return bool instead of int
Date: Fri, 22 Apr 2016 11:16:03 +0200 (CEST) [thread overview]
Message-ID: <alpine.DEB.2.11.1604221105310.3941@nanos> (raw)
In-Reply-To: <0C18FE92A7765D4EB9EE5D38D86A563A05D1B3D7@SHSMSX103.ccr.corp.intel.com>
On Fri, 22 Apr 2016, Du, Changbin wrote:
> > On Fri, 22 Apr 2016, changbin.du@intel.com wrote:
> > > A bad thing is that debug_object_fixup use the return value for
> > > arithmetic operation. It confused me that what is the reall return
> >
> > What's bad about that? The fact that it's used for arithmethic operation or
> > that it confused you?
> >
> It confused me because this is not a common usage. I was confused that what
> does he fixup function return? A countable value? But doc says return fixed
> or not!
It says return 0 for not fixed up and 1 for fixed up. The activate fixup is
special and it has been written this way to handle the static initialization
case.
> if (fixup)
> fixed = fixup(addr, state);
> debug_objects_fixups += fixed;
> In common,for int return 0 indicates success, negative for fail, positive
> for something countable. So I think it is better follow this rule. Here is
> not of countable, it is Boolean.
Yes, it's common for most of the code. This code has been deliberately been
written differently. I'm not opposed to change that and improve it, but just
slapping bool on it does not really make any difference.
> So why not this?
> if (fixup && fixup(addr, state))
> debug_objects_fixups++;
There is no problem with that per se.
> > > + bool (*fixup_init)(void *addr, enum debug_obj_state state);
> > > + bool (*fixup_activate)(void *addr, enum debug_obj_state state);
> > > + bool (*fixup_destroy)(void *addr, enum debug_obj_state state);
> > > + bool (*fixup_free)(void *addr, enum debug_obj_state state);
> > > + bool (*fixup_assert_init)(void *addr, enum debug_obj_state state);
> >
> > So this change will introduce a gazillion of compile warnings because the
> > callbacks in the various usage sites are still having 'int' return type.
> >
> No, I modified all the code who use debugojects API.
You do that in the later patches. But patches must be compilable and
functional on their own. Compiling this one will emit a gazillion of
"initialization from incompatible pointer type" warnings.
Thanks,
tglx
next prev parent reply other threads:[~2016-04-22 9:17 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-04-22 8:07 [PATCH 0/7] Make debugobjects fixup functions return bool type changbin.du
2016-04-22 8:07 ` [PATCH 1/7] debugobjects: make fixup functions return bool instead of int changbin.du
2016-04-22 8:33 ` Thomas Gleixner
2016-04-22 8:54 ` Du, Changbin
2016-04-22 9:16 ` Thomas Gleixner [this message]
2016-04-22 8:07 ` [PATCH 2/7] debugobjects: correct the usage of fixup call results changbin.du
2016-04-22 9:05 ` Thomas Gleixner
2016-04-22 8:07 ` [PATCH 3/7] workqueue: update debugobjects fixup callbacks return type changbin.du
2016-04-22 8:07 ` [PATCH 4/7] timer: " changbin.du
2016-04-22 8:07 ` [PATCH 5/7] rcu: " changbin.du
2016-04-22 8:07 ` [PATCH 6/7] percpu_counter: " changbin.du
2016-04-22 8:07 ` [PATCH 7/7] Documentation: update debugobjects doc changbin.du
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=alpine.DEB.2.11.1604221105310.3941@nanos \
--to=tglx@linutronix.de \
--cc=akpm@linux-foundation.org \
--cc=borntraeger@de.ibm.com \
--cc=changbin.du@intel.com \
--cc=corbet@lwn.net \
--cc=dchinner@redhat.com \
--cc=jiangshanlai@gmail.com \
--cc=john.stultz@linaro.org \
--cc=josh@joshtriplett.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mathieu.desnoyers@efficios.com \
--cc=paulmck@linux.vnet.ibm.com \
--cc=rostedt@goodmis.org \
--cc=tj@kernel.org \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®