Re: Avoiding #ifdefs

--- On Wed, 1/6/10, Bill Gatliff <[email protected]> wrote:

> From: Bill Gatliff <[email protected]>
> Subject: Re: Avoiding #ifdefs
> To: "CoDeBrEaKeR" <[email protected]>
> Cc: [email protected]
> Date: Wednesday, January 6, 2010, 7:43 PM
> Marek Vasut wrote:
> >>
> >> ifdefs here is what i want to avoid.
> >>
> >> +#ifdef CONFIG_MACH_OMAP_3630SDP
> >> +    .phy.venc.type   
>       = OMAP_DSS_VENC_TYPE_SVIDEO,
> >> +#else
> >> +    .phy.venc.type   
>       = OMAP_DSS_VENC_TYPE_COMPOSITE,
> >> +#endif
> >>
> >>     
> 
> I really don't think that this one is worth any effort to
> avoid, unless
> at some point it's possible that the condition might be
> passed in from
> the kernel command-line rather than just at compile-time.
> 
> Preprocessor macros serve a very useful purpose, and you
> should use them
> wherever they're appropriate.  The above example is
> probably an
> appropriate case, or at least is so mundane as to be
> harmless.

I wasn't too sure if it'll be accepted if i had to upstream it.

> 
> You used to see a lot of this in Linux kernel code:
> 
>     struct device_driver foo {
>     ...
>     #ifdef CONFIG_PM
>        .suspend = foo_suspend,
>        .resume = foo_resume,
>     #endif
>     ...
>     };
> 
>     #ifdef CONFIG_PM
>     int foo_suspend(...)
>     {...}
>     int foo_resume(...)
>     {...}
>     #endif
> 
> 
> That one got to be annoying because it was so redundant,
> and it made the
> #ifdef CONFIG_PM show up in multiple places.  A better
> approach has
> turned out to be:
> 
>     #ifdef CONFIG_PM
>     int foo_suspend(...)
>     {...}
>     #else
>     #define foo_suspend NULL
>     #endif
> 
> That lets you get rid of the #ifdef in the structure
> initializer,
> without resorting to runtime structure setup.  (Note
> that setting up the
> structure at runtime won't work if your kernel is
> execute-in-place).
> 
> If you have the same preprocessor macros showing up in many
> places,
> particularly when they're woven into your executable code,
> then you need
> to take a step back to see if there is a bigger-picture
> solution--- like
> the CONFIG_PM example above.  But don't sweat their
> occasional use, at
> all.  Just code it, and move on.  :)
> 

Thanks. I'll have it sent and see how it goes.

> 
> b.g.
> 
> -- 
> Bill Gatliff
> Embedded systems training and consulting
> http://billgatliff.com
> [email protected]
> 
> 
> _______________________________________________
> linux-arm mailing list
> [email protected]
> http://lists.infradead.org/mailman/listinfo/linux-arm
>