Re: [RFC|PATCH] Compile time printk verbosity
On Wed, Sep 2, 2009 at 05:47, Marc Andre Tanner wrote:
> On Wed, Sep 02, 2009 at 05:11:12AM -0400, Mike Frysinger wrote:
>> On Wed, Sep 2, 2009 at 04:57, Marc Andre Tanner wrote:
>> > On Tue, Sep 01, 2009 at 07:37:27PM -0400, Mike Frysinger wrote:
>> >> On Tue, Sep 1, 2009 at 18:31, Marc Andre Tanner wrote:
>> >> > This series adds a configuration option to selectively compile out
>> >> > printk message strings based on a verbosity level.
>> >> >
>> >> > This works by wrapping printk with a macro which evaluates to a
>> >> > constant if condition which the compiler will be able to optimize
>> >> > out.
>> >> >
>> >> > However because printk might be wrapped by a macro it no longer has
>> >> > a return value. This means that constructs like the following ones
>> >> > don't work:
>> >> >
>> >> > ((void)(SOME_RANDOM_DEBUG_FLAG && printk(...));
>> >> >
>> >> > some_random_variable = printk(...);
>> >> >
>> >> > Therefore printk_unfiltered is introduced which is just an alias
>> >> > to the standard printk function but not wrapped by a macro.
>> >>
>> >> why dont you return 0 if it gets optimized away ? then you wont have
>> >> to screw with external code at all and things "just work".
>> >
>> > This won't work because it would for example also return from functions
>> > which call printk but aren't checking for the return value (which is
>> > the common case).
>>
>> why would it matter ?
>>
>> ({
>> int __printk_ret = 0;
>> if (crazy stuff you're adding)
>> __printk_ret = printk(.);
>> __printk_ret;
>> })
>
> Yes I missunderstood your "return 0" statement in the first mail.
> The same effect could also be achieved by:
>
> ((crazy stuff) ? printk(...) : 0;
while true, i thought your (crazy stuff) pretty verbose and the
tertiary operator might get swallowed in the noise. not that it
matters that much to me as this is now a pure style choice ... your
patch, you pick.
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC|PATCH] Compile time printk verbosity
On Wed, Sep 02, 2009 at 05:11:12AM -0400, Mike Frysinger wrote:
> On Wed, Sep 2, 2009 at 04:57, Marc Andre Tanner wrote:
> > On Tue, Sep 01, 2009 at 07:37:27PM -0400, Mike Frysinger wrote:
> >> On Tue, Sep 1, 2009 at 18:31, Marc Andre Tanner wrote:
> >> > This series adds a configuration option to selectively compile out
> >> > printk message strings based on a verbosity level.
> >> >
> >> > This works by wrapping printk with a macro which evaluates to a
> >> > constant if condition which the compiler will be able to optimize
> >> > out.
> >> >
> >> > However because printk might be wrapped by a macro it no longer has
> >> > a return value. This means that constructs like the following ones
> >> > don't work:
> >> >
> >> > ((void)(SOME_RANDOM_DEBUG_FLAG && printk(...));
> >> >
> >> > some_random_variable = printk(...);
> >> >
> >> > Therefore printk_unfiltered is introduced which is just an alias
> >> > to the standard printk function but not wrapped by a macro.
> >>
> >> why dont you return 0 if it gets optimized away ? then you wont have
> >> to screw with external code at all and things "just work".
> >
> > This won't work because it would for example also return from functions
> > which call printk but aren't checking for the return value (which is
> > the common case).
>
> why would it matter ?
>
> ({
> int __printk_ret = 0;
> if (crazy stuff you're adding)
> __printk_ret = printk(.);
> __printk_ret;
> })
Yes I missunderstood your "return 0" statement in the first mail.
The same effect could also be achieved by:
((crazy stuff) ? printk(...) : 0;
Marc
--
Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC|PATCH] Compile time printk verbosity
On Wed, Sep 2, 2009 at 04:57, Marc Andre Tanner wrote:
> On Tue, Sep 01, 2009 at 07:37:27PM -0400, Mike Frysinger wrote:
>> On Tue, Sep 1, 2009 at 18:31, Marc Andre Tanner wrote:
>> > This series adds a configuration option to selectively compile out
>> > printk message strings based on a verbosity level.
>> >
>> > This works by wrapping printk with a macro which evaluates to a
>> > constant if condition which the compiler will be able to optimize
>> > out.
>> >
>> > However because printk might be wrapped by a macro it no longer has
>> > a return value. This means that constructs like the following ones
>> > don't work:
>> >
>> > ((void)(SOME_RANDOM_DEBUG_FLAG && printk(...));
>> >
>> > some_random_variable = printk(...);
>> >
>> > Therefore printk_unfiltered is introduced which is just an alias
>> > to the standard printk function but not wrapped by a macro.
>>
>> why dont you return 0 if it gets optimized away ? then you wont have
>> to screw with external code at all and things "just work".
>
> This won't work because it would for example also return from functions
> which call printk but aren't checking for the return value (which is
> the common case).
why would it matter ?
({
int __printk_ret = 0;
if (crazy stuff you're adding)
__printk_ret = printk(.);
__printk_ret;
})
-mike
--
To unsubscribe from this list: send the line "unsubscribe linux-embedded" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC|PATCH] Compile time printk verbosity
On Tue, Sep 01, 2009 at 07:37:27PM -0400, Mike Frysinger wrote: > On Tue, Sep 1, 2009 at 18:31, Marc Andre Tanner wrote: > > This series adds a configuration option to selectively compile out > > printk message strings based on a verbosity level. > > > > This works by wrapping printk with a macro which evaluates to a > > constant if condition which the compiler will be able to optimize > > out. > > > > However because printk might be wrapped by a macro it no longer has > > a return value. This means that constructs like the following ones > > don't work: > > > > ((void)(SOME_RANDOM_DEBUG_FLAG && printk(...)); > > > > some_random_variable = printk(...); > > > > Therefore printk_unfiltered is introduced which is just an alias > > to the standard printk function but not wrapped by a macro. > > why dont you return 0 if it gets optimized away ? then you wont have > to screw with external code at all and things "just work". This won't work because it would for example also return from functions which call printk but aren't checking for the return value (which is the common case). Or am I missing something? > -mike Marc -- Marc Andre Tanner >< http://www.brain-dump.org/ >< GPG key: CF7D56C0 -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [RFC|PATCH] Compile time printk verbosity
On Tue, Sep 1, 2009 at 18:31, Marc Andre Tanner wrote: > This series adds a configuration option to selectively compile out > printk message strings based on a verbosity level. > > This works by wrapping printk with a macro which evaluates to a > constant if condition which the compiler will be able to optimize > out. > > However because printk might be wrapped by a macro it no longer has > a return value. This means that constructs like the following ones > don't work: > > ((void)(SOME_RANDOM_DEBUG_FLAG && printk(...)); > > some_random_variable = printk(...); > > Therefore printk_unfiltered is introduced which is just an alias > to the standard printk function but not wrapped by a macro. why dont you return 0 if it gets optimized away ? then you wont have to screw with external code at all and things "just work". -mike -- To unsubscribe from this list: send the line "unsubscribe linux-embedded" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
