lkml.org 
[lkml]   [2014]   [Jan]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [RFC/PATCH 1/3] pm: make PM macros more smart
On Fri, Dec 20, 2013 at 12:23:36PM -0800, David Cohen wrote:
> On Fri, Dec 20, 2013 at 08:55:27PM +0100, Pavel Machek wrote:
> > On Sun 2013-12-15 11:25:08, David Cohen wrote:
> > > On Sun, Dec 15, 2013 at 06:51:12PM +0100, Pavel Machek wrote:
> > > > On Thu 2013-12-12 21:18:23, David Cohen wrote:
> > > > > This patch makes SET_SYSTEM_SLEEP_PM_OPS() and SET_RUNTIME_PM_OPS() more
> > > > > smart.
> > > > >
> > > > > Despite those macros check for '#ifdef CONFIG_PM_SLEEP/RUNTIME' to avoid
> > > > > setting the callbacks when such #ifdef's aren't defined, they don't
> > > > > handle compiler to avoid messages like that:
> > > > >
> > > > > drivers/usb/host/xhci-plat.c:200:12: warning: ???xhci_plat_suspend??? defined but not used [-Wunused-function]
> > > > > drivers/usb/host/xhci-plat.c:208:12: warning: ???xhci_plat_resume??? defined but not used [-Wunused-function]
> > > > >
> > > > > As result, those macros get rid of #ifdef's when setting callbacks but
> > > > > not when implementing them.
> > > > >
> > > > > With this patch, drivers using SET_*_PM_OPS() macros don't need to #ifdef
> > > > > the callbacks implementation as well.
> > > >
> > > > Well... Interesting trickery, but it means that resulting kernel
> > > > will be bigge due to the dead functions no?
> > >
> > > Actually, it doesn't get bigger. Before sending the patch I did this
> > > dummy test app:
> > >
> > > --------------------------------------------------------------------------------
> > > #include <stdio.h>
> > >
> > > #define USE_IT_OR_LOOSE_IT(fn) ((void *)((unsigned long)(fn) - (unsigned long)(fn)))
> > >
> > > #ifdef MAKE_ME_NULL
> > > static int func1(int a)
> > > {
> > > printf("Hey!!\n");
> > > return 0;
> > > }
> > > #endif
> >
> > I thought that point of this patch series was getting rid of the
> > #ifdefs around the function...? Now I'm confused.
>
> Maybe you're misinterpreting the test :)
>
> This #ifdef is used to make this same test code to replicate both
> scenarios according to -DMAKE_ME_NULL (just pay attention to actual
> resulting code after #ifdef's are tested. the #ifdef here is nor related
> to actual #ifdef on kernel). Here are both scenarios:
>
> (1) Not using my trickery (which needs the function to not be present).
> (2) Using my trickery (which needs to function to stay).
>
> With -DMAKE_ME_NULL we replicate (2), then the function *is* there but
> gcc gets rid of it on resulting binary without warnings if used with -O2.
>
> Without -DMAKE_ME_NULL we replicate (1). The #ifdef will fail and then
> remove the function which is an obvious scenario the function won't be
> part of resulting binary.
>
> If we use -S option to have human readable resulting assembly code
> (which is kind of 1:1 for resulting binary), we can compare the result
> of (1) and (2) and check they are pretty similar.
> This proves gcc behaves as expected with my patch: do not need #ifdef
> and do not generate dead codes to resulting binary.
>
> >
> > > struct global_data {
> > > int (*func)(int);
> > > };
> > >
> > > static struct global_data gd = {
> > > #ifdef MAKE_ME_NULL
> > > .func = USE_IT_OR_LOOSE_IT(func1),
> >
> > If you have ifdef around the function, why do you need magic here? Why
> > not
>
> This #ifdef is necessary to prevent the function to be used when it
> doesn't exist due to above #ifdef. But once again: don't misinterpret
> the #ifdefs in this test app with the ones in kernel. They are not
> related at all. If it's still confusing you just make 2 test apps
> without #ifdeds out of this one where one keeps the code inside #ifdefs
> and the other doesn't.
>
> >
> > .func = func1
> >
> > ?
> >
> > Basically the warning tells you that you want the ifdef around the
> > function, too... (Otherwise you waste space). That seems like good
> > warning.
>
> Just check my first explanation.

Ping :)

Comments here?

Br, David Cohen


\
 
 \ /
  Last update: 2014-01-15 00:01    [W:0.045 / U:0.356 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site