2009/9/2 Marc Andre Tanner :
> On Wed, Sep 02, 2009 at 06:44:19PM +0200, Marco Stornelli wrote:
>>
>>
>> Marc Andre Tanner ha scritto:
>> > +#define printk(fmt, ...) (
>> > \
>>
>> Shouldn't it be an and?
>
> Don't think so. If the expression
Johannes Stezenbach wrote:
What I'm interested in are some numbers for similar hardware,
to find out if my hardware and/or ethernet driver can be improved,
or if the CPU will always be the limiting factor.
I'd also be interested to know if hardware checksumming
support would improve throughput no
On Wednesday, September 02, 2009 10:05 AM, Tim Bird wrote:
> Marc Andre Tanner wrote:
>> On Tue, Sep 01, 2009 at 07:32:25PM -0400, H Hartley Sweeten wrote:
>>> On Tuesday, September 01, 2009 4:24 PM, Tim Bird wrote:
Some places in the kernel break the message into pieces, like so:
pr
On Wed, Sep 02, 2009 at 06:44:06PM +0200, Marco Stornelli wrote:
> Marc Andre Tanner ha scritto:
> > Introduce a config option which allows to selectively compile out
> > printk messages based on a specified verbosity level.
> >
> > Signed-off-by: Marc Andre Tanner
> > ---
> > init/Kconfig | 2
On Wed, Sep 02, 2009 at 06:44:19PM +0200, Marco Stornelli wrote:
>
>
> Marc Andre Tanner ha scritto:
> > +#define printk(fmt, ...) (
> > \
>
> Shouldn't it be an and?
Don't think so. If the expression isn't constant we are unable to filte
Tim Bird wrote:
> Marc Andre Tanner wrote:
>> On Tue, Sep 01, 2009 at 07:32:25PM -0400, H Hartley Sweeten wrote:
>>> On Tuesday, September 01, 2009 4:24 PM, Tim Bird wrote:
Some places in the kernel break the message into pieces, like so:
printk(KERN_ERR, "Error: first part ");
Marc Andre Tanner wrote:
> On Tue, Sep 01, 2009 at 07:32:25PM -0400, H Hartley Sweeten wrote:
>> On Tuesday, September 01, 2009 4:24 PM, Tim Bird wrote:
>>> Some places in the kernel break the message into pieces, like so:
>>>
>>> printk(KERN_ERR, "Error: first part ");
>>> ...
>>> printk(" more in
Marc Andre Tanner ha scritto:
> +#define printk(fmt, ...) (
> \
Shouldn't it be an and?
> + (!__builtin_constant_p(PRINTK_FILTER((fmt))) || PRINTK_FILTER((fmt))) ?
> \
> + printk((fmt), ##__VA_ARGS__) : 0
Marc Andre Tanner ha scritto:
> Introduce a config option which allows to selectively compile out
> printk messages based on a specified verbosity level.
>
> Signed-off-by: Marc Andre Tanner
> ---
> init/Kconfig | 29 +
> 1 files changed, 29 insertions(+), 0 deletio
The macro filters out printk messages based on a configurable verbosity
level (CONFIG_PRINTK_VERBOSITY).
Signed-off-by: Marc Andre Tanner
---
include/linux/kernel.h | 23 +++
1 files changed, 23 insertions(+), 0 deletions(-)
diff --git a/include/linux/kernel.h b/include/li
We don't want to filter user space data which comes from /dev/kmsg.
Signed-off-by: Marc Andre Tanner
---
drivers/char/mem.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/char/mem.c b/drivers/char/mem.c
index afa8813..ba48b82 100644
--- a/drivers/char/mem.c
+++
The standard printk function will be wrapped by a macro which
filters out messages above a certain verbosity level. Because
this might not be desired in certain situations we provide an
unfiltered variant.
Signed-off-by: Marc Andre Tanner
---
include/linux/kernel.h |5 +
kernel/printk.c
A later patch will #undef printk because the macro would otherwise
conflict with the function definition. Moving the printk function
to the end of the file makes sure that the macro is expanded within
the rest of the file.
Signed-off-by: Marc Andre Tanner
---
kernel/printk.c | 72 +
Introduce a config option which allows to selectively compile out
printk messages based on a specified verbosity level.
Signed-off-by: Marc Andre Tanner
---
init/Kconfig | 29 +
1 files changed, 29 insertions(+), 0 deletions(-)
diff --git a/init/Kconfig b/init/Kcon
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.
For situation were this filtering mechanis
Mike Frysinger wrote:
> it depends completely on how the macro is intended to be used. if you
> want to maintain the "this macro has a return value", then you have to
> use ({...}). if you want the macro to return a void, then you have to
> use do{...}while(0).
Actually no. The difference is do
On Wed, Sep 02, 2009 at 08:54:47AM -0400, Mike Frysinger wrote:
> On Wed, Sep 2, 2009 at 08:44, Marc Andre Tanner wrote:
> > On Wed, Sep 02, 2009 at 07:25:43AM -0500, Bill Gatliff wrote:
> >> Jamie Lokier wrote:
> >> >Looks good, except that I think kernel style is to use "do {...} while
> >> >(0)"
On Tue, Sep 01, 2009 at 07:32:25PM -0400, H Hartley Sweeten wrote:
> On Tuesday, September 01, 2009 4:24 PM, Tim Bird wrote:
> > Some places in the kernel break the message into pieces, like so:
> >
> > printk(KERN_ERR, "Error: first part ");
> > ...
> > printk(" more info for error.\n");
>
> Tech
On Wed, Sep 2, 2009 at 08:44, Marc Andre Tanner wrote:
> On Wed, Sep 02, 2009 at 07:25:43AM -0500, Bill Gatliff wrote:
>> Jamie Lokier wrote:
>> >Looks good, except that I think kernel style is to use "do {...} while
>> >(0)" rather than "({ ... })"
>>
>> And IIRC, there was some reason for the do{
On Wed, Sep 02, 2009 at 07:25:43AM -0500, Bill Gatliff wrote:
> Jamie Lokier wrote:
> >Looks good, except that I think kernel style is to use "do {...} while
> >(0)" rather than "({ ... })"
>
> And IIRC, there was some reason for the do{...} while(0) that made
> other alternatives not work. So it
Jamie Lokier wrote:
Looks good, except that I think kernel style is to use "do {...} while
(0)" rather than "({ ... })"
And IIRC, there was some reason for the do{...} while(0) that made other
alternatives not work. So it might be more than just style at issue.
b.g.
--
Bill Gatliff
b..
Marc Andre Tanner wrote:
> Thanks, so if I understood it correctly this should be used like this:
>
> #define PRINTK_FILTER(fmt) (
> \
> (((const char *)(fmt))[0] != '<' && CONFIG_PRINTK_VERBOSITY >= 4) ||
> \
> (((const char *)(fmt
On Wed, Sep 02, 2009 at 11:03:13AM +0200, Marc Andre Tanner wrote:
> On Wed, Sep 02, 2009 at 12:35:42AM +0100, Jamie Lokier wrote:
> > Marc Andre Tanner wrote:
> > > + * The check with sizeof(void*) should make sure that we don't operate on
> > > + * pointers, which the compiler wouldn't be able to
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 Tann
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
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
On Wed, Sep 02, 2009 at 12:35:42AM +0100, Jamie Lokier wrote:
> Marc Andre Tanner wrote:
> > + * The check with sizeof(void*) should make sure that we don't operate on
> > + * pointers, which the compiler wouldn't be able to optimize out, but only
> > + * on string constants.
>
> Take a look at __
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 w
28 matches
Mail list logo
