On Sun, 5 Jun 2011, Felipe Balbi wrote:
> > > good point. BTW, do we need this #ifdef CONFIG_PM stuff which has been
> > > popping on most drivers recently ? To me it looks like driver.pm field
> > > is always available even if PM is disabled, so what's the point ? Saving
> > > a few bytes ?
> >
> > Basically, yes (you may want to avoid defining the object this points to if
> > CONFIG_PM is unset).
>
> wouldn't it look nicer to have a specific section for dev_pm_ops which
> gets automatically freed if CONFIG_PM isn't set ? I mean, there are a
> few drivers which don't have the ifdeferry around dev_pm_ops anyway.
>
> So, something like:
>
> #define __pm_ops __section(.pm.ops)
>
> static const struct dev_pm_ops my_driver_pm_ops __pm_ops = {
> .suspend = my_driver_suspend,
> .resume = my_driver_resume,
> [ blablabla ]
> };
>
> to simplify things, you could:
>
> #define DEFINE_DEV_PM_OPS(_ops) \
> const struct dev_pm_ops _ops __pm_ops
>
> that would mean changes to all linker scripts, though and a utility call
> that only does anything ifndef CONFIG_PM to free the .pm.ops section.
In my opinion this would make programming harder, not easier. It's
very easy to understand "#ifdef" followed by "#endif"; people see them
all the time. The new tags you propose would force people to go
searching through tons of source files to see what they mean, and then
readers would still have to figure out when these tags should be used
or what advantage they might bring.
It's a little like "typedef struct foo foo_t;" -- doing this forces
people to remember one extra piece of information that serves no real
purpose except perhaps a minimal reduction in the amount of typing.
Since the limiting factor in kernel programming is human brainpower,
not source file length, this is a bad tradeoff. (Not to mention that
it also obscures an important fact: A foo_t is an extended structure
rather than a single value.)
Alan Stern
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
