On Fri, 28 September 2007 10:39:06 +0200, Bernd Petrovitsch wrote:
>
> If think you misunderstood:
> Say, you compile out everything of DEBUG level.
> Say, you have a continued printk() after each and every pr_debug().
>
> Then how is the macro supposed to know (at compile-time) that the
>
On Fri, 28 September 2007 10:39:06 +0200, Bernd Petrovitsch wrote:
If think you misunderstood:
Say, you compile out everything of DEBUG level.
Say, you have a continued printk() after each and every pr_debug().
Then how is the macro supposed to know (at compile-time) that the
continued
Rob Landley <[EMAIL PROTECTED]> wrote:
| The "change every printk in the kernel" suggestion came from me trying to
| figure out how to get the printk() calls below a certain log level to
| optimize out and not take up space in the binary.
|
| The above doesn't address the original cause of the
On Fre, 2007-09-28 at 00:21 +0200, Arnd Bergmann wrote:
> On Thursday 27 September 2007, you wrote:
> > > Then you don't have to change every single printk in the kernel, but
> > > only those that don't currently come with a log level. More importantly,
> > > you can do the conversion without a
Rob Landley [EMAIL PROTECTED] wrote:
| The change every printk in the kernel suggestion came from me trying to
| figure out how to get the printk() calls below a certain log level to
| optimize out and not take up space in the binary.
|
| The above doesn't address the original cause of the
On Fre, 2007-09-28 at 00:21 +0200, Arnd Bergmann wrote:
On Thursday 27 September 2007, you wrote:
Then you don't have to change every single printk in the kernel, but
only those that don't currently come with a log level. More importantly,
you can do the conversion without a flag day, by
On Thursday 27 September 2007 2:00:36 am Arnd Bergmann wrote:
> #define KERN_NOTICE "<5>",
>
> #define PRINTK_CONTINUED "",
>
> #define printk(level, str, ...) \
>do { \
> if (sizeof(level) == 1) /* continued printk */\
> actual_printk(str, __VA_ARGS__); \
> else if ((level[1]
On Thursday 27 September 2007, you wrote:
> > Then you don't have to change every single printk in the kernel, but
> > only those that don't currently come with a log level. More importantly,
> > you can do the conversion without a flag day, by spreading (an empty)
> > PRINTK_CONTINUED in places
On Thu, September 27, 2007 09:00, Arnd Bergmann wrote:
> Assuming that we want to go down that road, I think you can do better with
> more evil macro magic, by using something along the lines of
>
> #define KERN_NOTICE "<5>",
>
> #define PRINTK_CONTINUED "",
>
> #define printk(level, str, ...) \
On Thursday 20 September 2007, you wrote:
> So instead of:
> printk(KERN_NOTICE "Fruit=%d\n", banana);
> It would now be:
> printk(KERN_NOTICE, "Fruit=%d\n", banana);
>
> Change the header from:
> #define KERN_NOTICE "<5>"
> to:
> #define KERN_NOTICE 5
>
> Then you can change the printk
On Thursday 20 September 2007, you wrote:
So instead of:
printk(KERN_NOTICE Fruit=%d\n, banana);
It would now be:
printk(KERN_NOTICE, Fruit=%d\n, banana);
Change the header from:
#define KERN_NOTICE 5
to:
#define KERN_NOTICE 5
Then you can change the printk guts to do
On Thu, September 27, 2007 09:00, Arnd Bergmann wrote:
Assuming that we want to go down that road, I think you can do better with
more evil macro magic, by using something along the lines of
#define KERN_NOTICE 5,
#define PRINTK_CONTINUED ,
#define printk(level, str, ...) \
do { \
On Thursday 27 September 2007, you wrote:
Then you don't have to change every single printk in the kernel, but
only those that don't currently come with a log level. More importantly,
you can do the conversion without a flag day, by spreading (an empty)
PRINTK_CONTINUED in places that do
On Thursday 27 September 2007 2:00:36 am Arnd Bergmann wrote:
#define KERN_NOTICE 5,
#define PRINTK_CONTINUED ,
#define printk(level, str, ...) \
do { \
if (sizeof(level) == 1) /* continued printk */\
actual_printk(str, __VA_ARGS__); \
else if ((level[1] - '0')
On Monday 24 September 2007 1:13:07 pm Adrian Bunk wrote:
> The simplest solution that comes into my mind would be to create links
> for the source file in the output dir before calling gcc and then give
> gcc the link as input file.
The way I've been building various packages out-of-tree
On Monday 24 September 2007 1:13:07 pm Adrian Bunk wrote:
The simplest solution that comes into my mind would be to create links
for the source file in the output dir before calling gcc and then give
gcc the link as input file.
The way I've been building various packages out-of-tree (including
On Thu, 20 Sep 2007, Joe Perches wrote:
> On Thu, 2007-09-20 at 15:38 -0500, Rob Landley wrote:
> > And so far no behavior has changed. But now the _fun_ part is, you can add
> > a
> > config symbol for "what is the minimum loglevel I care about?" Set that as
> > a
> > number from 0-9. And
On Thu, 20 Sep 2007, Joe Perches wrote:
On Thu, 2007-09-20 at 15:38 -0500, Rob Landley wrote:
And so far no behavior has changed. But now the _fun_ part is, you can add
a
config symbol for what is the minimum loglevel I care about? Set that as
a
number from 0-9. And then you can
On Fri, Sep 21, 2007 at 08:29:49AM +0200, Sam Ravnborg wrote:
>...
> So __FILE__ expand differently depending on the path on
> the gcc command line.
> I once posted a patch to fix up on this, especialy for BUG_ON and friends.
> The solution was to let kbuild generate the filename and to use
> this
On Fri, Sep 21, 2007 at 08:29:49AM +0200, Sam Ravnborg wrote:
...
So __FILE__ expand differently depending on the path on
the gcc command line.
I once posted a patch to fix up on this, especialy for BUG_ON and friends.
The solution was to let kbuild generate the filename and to use
this
On Fri, Sep 21, 2007 at 04:15:39PM -0500, Rob Landley wrote:
[]
> > >Not all, but critical info, that must exist in human-readable form of
> > >course.
> >
> > I disagree. For a production product the you want minimal information
> > to reduce the communication bandwidth required between the
On Fri, 2007-09-21 at 18:05 -0500, Rob Landley wrote:
> > from printks and defining something that modifies pr_.
> pr_level doesn't exist in mainline.
pr_info and pr_debug do.
pr_alert, pr_emerg, pr_crit, pr_err, and pr_warn could be added.
> > #define pr_info(fmt, arg) printk(KERN_INFO PR_FMT
On Friday 21 September 2007 12:45:27 pm Joe Perches wrote:
> On Fri, 2007-09-21 at 13:16 -0400, [EMAIL PROTECTED] wrote:
> > What about something *really* hardcore ugly like:
> > #ifdef __FILE__
> > #undef __FILE__
> > #define __FILE__ ""
> > #endif
> > (or similar preprocessor blecherousness) if
On Sep 21, 2007, at 18:05:34, Joe Perches wrote:
On Fri, 2007-09-21 at 17:34 -0400, Kyle Moffett wrote:
With a bit more glue that would cause GCC to notice that for a
given qprintk_kmalloc the "qpk->type" is always zero because the
level is too high, and therefore it would optimize out *ALL*
ct: RE: Message codes (Re: [Announce] Linux-tiny project revival)
>
>On Fri, 2007-09-21 at 15:12 -0700, Gross, Mark wrote:
>> Use compiler tricks to remove ALL the static printk string from
>> the kernel and replace the printk with something that outputs a
>> decimal index
On Fri, 2007-09-21 at 15:12 -0700, Gross, Mark wrote:
> Use compiler tricks to remove ALL the static printk string from
> the kernel and replace the printk with something that outputs a
> decimal index followed by tuples, of zero to N, hex-strings on
> I proposed a mechanism for keeping all the
>> >Cc: Rob Landley; Alexey Dobriyan; Michael Opdenacker; linux-
>> >[EMAIL PROTECTED]; CE Linux Developers List; linux kernel
>> >Subject: Message codes (Re: [Announce] Linux-tiny project revival)
>> >
>> >* Thu, 20 Sep 2007 15:15:47 -0700
>> >
On Fri, 2007-09-21 at 17:34 -0400, Kyle Moffett wrote:
> With a bit more glue that would cause GCC to notice that for a given
> qprintk_kmalloc the "qpk->type" is always zero because the level is
> too high, and therefore it would optimize out *ALL* of the
> _qprintk_kmalloc(), _qprintk(),
On Sep 20, 2007, at 19:18:41, Rob Landley wrote:
On Thursday 20 September 2007 4:26:13 pm Indan Zupancic wrote:
But the problem remains that there are printk's which don't have a
KERN_* as the first argument. Those are also impossible to get rid
off in this way, as the loglevel is unknown
> >[EMAIL PROTECTED]; CE Linux Developers List; linux kernel
> >Subject: Message codes (Re: [Announce] Linux-tiny project revival)
> >
> >* Thu, 20 Sep 2007 15:15:47 -0700
> >* X-MimeOLE: Produced By Microsoft Exchange V6.5
> >[]
> >
> >>>*Sh
On Fri, 2007-09-21 at 13:16 -0400, [EMAIL PROTECTED] wrote:
> What about something *really* hardcore ugly like:
> #ifdef __FILE__
> #undef __FILE__
> #define __FILE__ ""
> #endif
> (or similar preprocessor blecherousness) if you want to *really* shrink
> that binary down?
I prefer removing all
On Thu, 20 Sep 2007 18:18:41 CDT, Rob Landley said:
> Worse, if you feed an absolute path to O= when you build the kernel out of
> tree, then it uses absolute paths for all the __FILE__ strings and that makes
> kernel BIG. (Did that by accident a while back.) Too bad there's no way
> to
codes (Re: [Announce] Linux-tiny project revival)
>
>* Thu, 20 Sep 2007 15:15:47 -0700
>* X-MimeOLE: Produced By Microsoft Exchange V6.5
>[]
>>>*Shrug*.
>>>
>>>My problem is that switching off printk is the single biggest bloat
>> cutter
>>&
Rob Landley <[EMAIL PROTECTED]> wrote:
| I'm proposing allowing an ignore_loglevel to remove the unused messages at
| compile time so they don't take up space. Doing that requires the levels to
| be integers so they can be compared with < or >, and the remaining changes
| follow logically.
- Original Message
From: Tim Bird <[EMAIL PROTECTED]>
Rob Landley wrote:
Given that there are about 60,000 printks in the kernel (and that's
not counting wrappers like dprintk() and other locally-defined
functions and macros) it would be a huge task to examine the code
and
Rob Landley wrote:
On Wednesday 19 September 2007 1:03:09 pm Tim Bird wrote:
Recently, the CE Linux forum has been working to revive the
Linux-tiny project. At OLS, I asked for interested parties
to volunteer to become the new maintainer for the Linux-tiny patchset.
A few candidates came
On Fri, Sep 21, 2007 at 01:06:21AM +0200, Indan Zupancic wrote:
> On Fri, September 21, 2007 01:18, Rob Landley wrote:
> > On Thursday 20 September 2007 4:26:13 pm Indan Zupancic wrote:
> >> A quick scroll through a vmlinux binary shows that there are quite a
> >> lot areas consisting only of some
On Fri, Sep 21, 2007 at 01:06:21AM +0200, Indan Zupancic wrote:
On Fri, September 21, 2007 01:18, Rob Landley wrote:
On Thursday 20 September 2007 4:26:13 pm Indan Zupancic wrote:
A quick scroll through a vmlinux binary shows that there are quite a
lot areas consisting only of some repeated
Rob Landley wrote:
On Wednesday 19 September 2007 1:03:09 pm Tim Bird wrote:
Recently, the CE Linux forum has been working to revive the
Linux-tiny project. At OLS, I asked for interested parties
to volunteer to become the new maintainer for the Linux-tiny patchset.
A few candidates came
- Original Message
From: Tim Bird [EMAIL PROTECTED]
Rob Landley wrote:
Given that there are about 60,000 printks in the kernel (and that's
not counting wrappers like dprintk() and other locally-defined
functions and macros) it would be a huge task to examine the code
and differentiate
Rob Landley [EMAIL PROTECTED] wrote:
| I'm proposing allowing an ignore_loglevel to remove the unused messages at
| compile time so they don't take up space. Doing that requires the levels to
| be integers so they can be compared with or , and the remaining changes
| follow logically. (To
-tiny project revival)
* Thu, 20 Sep 2007 15:15:47 -0700
* X-MimeOLE: Produced By Microsoft Exchange V6.5
[]
*Shrug*.
My problem is that switching off printk is the single biggest bloat
cutter
in
the kernel, yet it makes the resulting system very hard to support.
It
combines a big upside with a big
On Thu, 20 Sep 2007 18:18:41 CDT, Rob Landley said:
Worse, if you feed an absolute path to O= when you build the kernel out of
tree, then it uses absolute paths for all the __FILE__ strings and that makes
kernel BIG. (Did that by accident a while back.) Too bad there's no way
to keep
On Fri, 2007-09-21 at 13:16 -0400, [EMAIL PROTECTED] wrote:
What about something *really* hardcore ugly like:
#ifdef __FILE__
#undef __FILE__
#define __FILE__
#endif
(or similar preprocessor blecherousness) if you want to *really* shrink
that binary down?
I prefer removing all __FILE__,
; linux kernel
Subject: Message codes (Re: [Announce] Linux-tiny project revival)
* Thu, 20 Sep 2007 15:15:47 -0700
* X-MimeOLE: Produced By Microsoft Exchange V6.5
[]
*Shrug*.
My problem is that switching off printk is the single biggest bloat
cutter
in
the kernel, yet it makes
On Sep 20, 2007, at 19:18:41, Rob Landley wrote:
On Thursday 20 September 2007 4:26:13 pm Indan Zupancic wrote:
But the problem remains that there are printk's which don't have a
KERN_* as the first argument. Those are also impossible to get rid
off in this way, as the loglevel is unknown
On Fri, 2007-09-21 at 17:34 -0400, Kyle Moffett wrote:
With a bit more glue that would cause GCC to notice that for a given
qprintk_kmalloc the qpk-type is always zero because the level is
too high, and therefore it would optimize out *ALL* of the
_qprintk_kmalloc(), _qprintk(), and
Linux Developers List; linux kernel
Subject: Message codes (Re: [Announce] Linux-tiny project revival)
* Thu, 20 Sep 2007 15:15:47 -0700
* X-MimeOLE: Produced By Microsoft Exchange V6.5
[]
*Shrug*.
My problem is that switching off printk is the single biggest
bloat
cutter
On Fri, 2007-09-21 at 15:12 -0700, Gross, Mark wrote:
Use compiler tricks to remove ALL the static printk string from
the kernel and replace the printk with something that outputs a
decimal index followed by tuples, of zero to N, hex-strings on
I proposed a mechanism for keeping all the
: [Announce] Linux-tiny project revival)
On Fri, 2007-09-21 at 15:12 -0700, Gross, Mark wrote:
Use compiler tricks to remove ALL the static printk string from
the kernel and replace the printk with something that outputs a
decimal index followed by tuples, of zero to N, hex-strings on
I proposed
On Sep 21, 2007, at 18:05:34, Joe Perches wrote:
On Fri, 2007-09-21 at 17:34 -0400, Kyle Moffett wrote:
With a bit more glue that would cause GCC to notice that for a
given qprintk_kmalloc the qpk-type is always zero because the
level is too high, and therefore it would optimize out *ALL* of
On Friday 21 September 2007 12:45:27 pm Joe Perches wrote:
On Fri, 2007-09-21 at 13:16 -0400, [EMAIL PROTECTED] wrote:
What about something *really* hardcore ugly like:
#ifdef __FILE__
#undef __FILE__
#define __FILE__
#endif
(or similar preprocessor blecherousness) if you want to
On Fri, 2007-09-21 at 18:05 -0500, Rob Landley wrote:
from printks and defining something that modifies pr_level.
pr_level doesn't exist in mainline.
pr_info and pr_debug do.
pr_alert, pr_emerg, pr_crit, pr_err, and pr_warn could be added.
#define pr_info(fmt, arg) printk(KERN_INFO PR_FMT
On Fri, Sep 21, 2007 at 04:15:39PM -0500, Rob Landley wrote:
[]
Not all, but critical info, that must exist in human-readable form of
course.
I disagree. For a production product the you want minimal information
to reduce the communication bandwidth required between the remote
* Thu, 20 Sep 2007 15:15:47 -0700
* X-MimeOLE: Produced By Microsoft Exchange V6.5
[]
>>*Shrug*.
>>
>>My problem is that switching off printk is the single biggest bloat
> cutter
>>in
>>the kernel, yet it makes the resulting system very hard to support. It
>>combines a big upside with a big
On Thu, 2007-09-20 at 19:28 -0500, Rob Landley wrote:
> You convert printk(KERN_INFO, blah) to pr_INFO(blah)?
more or less.
printk(KERN_INFO foo) to pr_info(foo)
printk(KERN_EMERG foo) to pr_emerge(foo)
etc.
> I'm not finding pr_INFO with a grep on the files in
> 2.6.23-rc7.
I haven't
On Thursday 20 September 2007 5:14:25 pm Joe Perches wrote:
> On Thu, 2007-09-20 at 14:58 -0700, Tim Bird wrote:
> > Given that there are about 60,000 printks in the kernel (and that's
> > not counting wrappers like dprintk() and other locally-defined
> > functions and macros) it would be a huge
On Fri, September 21, 2007 01:18, Rob Landley wrote:
> On Thursday 20 September 2007 4:26:13 pm Indan Zupancic wrote:
>> A quick scroll through a vmlinux binary shows that there are quite a
>> lot areas consisting only of some repeated pattern. Mostly 0x00, but
>> also 0x90 and ".GCC: (GNU)
On Thursday 20 September 2007 4:26:13 pm Indan Zupancic wrote:
> On Thu, September 20, 2007 22:38, Rob Landley wrote:
> > I've been playing with an idea for a while to improve the printk()
> > situation, but it's a more intrusive change than I've had time to bang
> > on.
> >
> > Right now, the
On Thu, 2007-09-20 at 14:58 -0700, Tim Bird wrote:
> Given that there are about 60,000 printks in the kernel (and that's
> not counting wrappers like dprintk() and other locally-defined
> functions and macros) it would be a huge task to examine the code
> and differentiate strings that really
ubject: [Celinux-dev] Re: [Announce] Linux-tiny project revival
>
>On Thursday 20 September 2007 2:58:44 pm Alexey Dobriyan wrote:
>> On Thu, Sep 20, 2007 at 03:38:42PM -0500, Rob Landley wrote:
>> > I've been playing with an idea for a while to improve the printk()
>> >
On Thursday 20 September 2007 4:58:54 pm Tim Bird wrote:
> Rob Landley wrote:
> > So instead of:
> > printk(KERN_NOTICE "Fruit=%d\n", banana);
> > It would now be:
> > printk(KERN_NOTICE, "Fruit=%d\n", banana);
> >
> > Change the header from:
> > #define KERN_NOTICE "<5>"
> > to:
> >
On Wednesday 19 September 2007 4:28:05 pm Andrew Morton wrote:
> On Wed, 19 Sep 2007 11:03:09 -0700
>
> Tim Bird <[EMAIL PROTECTED]> wrote:
> > Recently, the CE Linux forum has been working to revive the
> > Linux-tiny project. At OLS, I asked for interested parties
> > to volunteer to become the
On Thu, September 20, 2007 22:38, Rob Landley wrote:
> I've been playing with an idea for a while to improve the printk() situation,
> but it's a more intrusive change than I've had time to bang on.
>
> Right now, the first argument to printk() is a loglevel, but it's handled via
> string
Rob Landley wrote:
> So instead of:
> printk(KERN_NOTICE "Fruit=%d\n", banana);
> It would now be:
> printk(KERN_NOTICE, "Fruit=%d\n", banana);
>
> Change the header from:
> #define KERN_NOTICE "<5>"
> to:
> #define KERN_NOTICE 5
>
> Then you can change the printk guts to do something
On Thursday 20 September 2007 4:22:37 pm Jared Hulbert wrote:
> > > I think that this idea is not worth it.
>
> Don't use the config option then
>
> > My problem is that switching off printk is the single biggest bloat
> > cutter in the kernel, yet it makes the resulting system very hard to
>
> > I think that this idea is not worth it.
Don't use the config option then
> My problem is that switching off printk is the single biggest bloat cutter in
> the kernel, yet it makes the resulting system very hard to support. It
> combines a big upside with a big downside, and I'd like
On Thursday 20 September 2007 2:58:44 pm Alexey Dobriyan wrote:
> On Thu, Sep 20, 2007 at 03:38:42PM -0500, Rob Landley wrote:
> > I've been playing with an idea for a while to improve the printk()
> > situation, but it's a more intrusive change than I've had time to bang
> > on.
> >
> > Right
On Thu, 2007-09-20 at 15:38 -0500, Rob Landley wrote:
> And so far no behavior has changed. But now the _fun_ part is, you can add a
> config symbol for "what is the minimum loglevel I care about?" Set that as a
> number from 0-9. And then you can define the printk to do:
>
> #define
On Thu, Sep 20, 2007 at 03:38:42PM -0500, Rob Landley wrote:
> I've been playing with an idea for a while to improve the printk() situation,
> but it's a more intrusive change than I've had time to bang on.
>
> Right now, the first argument to printk() is a loglevel, but it's handled via
>
On Wednesday 19 September 2007 1:03:09 pm Tim Bird wrote:
> Recently, the CE Linux forum has been working to revive the
> Linux-tiny project. At OLS, I asked for interested parties
> to volunteer to become the new maintainer for the Linux-tiny patchset.
>
> A few candidates came forward, but
On Thu, Sep 20, 2007 at 12:38:55AM +0200, Michael Opdenacker wrote:
> Andrew, you're completely right... The patches should all aim at being
> included into mainline or die.
>
> I'm finishing a sequence of crazy weeks and I will have time to send you
> patches one by one next week, starting with
On Thu, Sep 20, 2007 at 12:38:55AM +0200, Michael Opdenacker wrote:
Andrew, you're completely right... The patches should all aim at being
included into mainline or die.
I'm finishing a sequence of crazy weeks and I will have time to send you
patches one by one next week, starting with the
On Wednesday 19 September 2007 1:03:09 pm Tim Bird wrote:
Recently, the CE Linux forum has been working to revive the
Linux-tiny project. At OLS, I asked for interested parties
to volunteer to become the new maintainer for the Linux-tiny patchset.
A few candidates came forward, but
On Thu, Sep 20, 2007 at 03:38:42PM -0500, Rob Landley wrote:
I've been playing with an idea for a while to improve the printk() situation,
but it's a more intrusive change than I've had time to bang on.
Right now, the first argument to printk() is a loglevel, but it's handled via
string
On Thu, 2007-09-20 at 15:38 -0500, Rob Landley wrote:
And so far no behavior has changed. But now the _fun_ part is, you can add a
config symbol for what is the minimum loglevel I care about? Set that as a
number from 0-9. And then you can define the printk to do:
#define printk(level,
On Thursday 20 September 2007 2:58:44 pm Alexey Dobriyan wrote:
On Thu, Sep 20, 2007 at 03:38:42PM -0500, Rob Landley wrote:
I've been playing with an idea for a while to improve the printk()
situation, but it's a more intrusive change than I've had time to bang
on.
Right now, the first
I think that this idea is not worth it.
Don't use the config option then
My problem is that switching off printk is the single biggest bloat cutter in
the kernel, yet it makes the resulting system very hard to support. It
combines a big upside with a big downside, and I'd like
On Thursday 20 September 2007 4:22:37 pm Jared Hulbert wrote:
I think that this idea is not worth it.
Don't use the config option then
My problem is that switching off printk is the single biggest bloat
cutter in the kernel, yet it makes the resulting system very hard to
support.
On Thu, September 20, 2007 22:38, Rob Landley wrote:
I've been playing with an idea for a while to improve the printk() situation,
but it's a more intrusive change than I've had time to bang on.
Right now, the first argument to printk() is a loglevel, but it's handled via
string
Rob Landley wrote:
So instead of:
printk(KERN_NOTICE Fruit=%d\n, banana);
It would now be:
printk(KERN_NOTICE, Fruit=%d\n, banana);
Change the header from:
#define KERN_NOTICE 5
to:
#define KERN_NOTICE 5
Then you can change the printk guts to do something vaguely like
On Wednesday 19 September 2007 4:28:05 pm Andrew Morton wrote:
On Wed, 19 Sep 2007 11:03:09 -0700
Tim Bird [EMAIL PROTECTED] wrote:
Recently, the CE Linux forum has been working to revive the
Linux-tiny project. At OLS, I asked for interested parties
to volunteer to become the new
On Thursday 20 September 2007 4:58:54 pm Tim Bird wrote:
Rob Landley wrote:
So instead of:
printk(KERN_NOTICE Fruit=%d\n, banana);
It would now be:
printk(KERN_NOTICE, Fruit=%d\n, banana);
Change the header from:
#define KERN_NOTICE 5
to:
#define KERN_NOTICE 5
Then
On Thu, 2007-09-20 at 14:58 -0700, Tim Bird wrote:
Given that there are about 60,000 printks in the kernel (and that's
not counting wrappers like dprintk() and other locally-defined
functions and macros) it would be a huge task to examine the code
and differentiate strings that really start a
] Linux-tiny project revival
On Thursday 20 September 2007 2:58:44 pm Alexey Dobriyan wrote:
On Thu, Sep 20, 2007 at 03:38:42PM -0500, Rob Landley wrote:
I've been playing with an idea for a while to improve the printk()
situation, but it's a more intrusive change than I've had time to
bang
On Thursday 20 September 2007 4:26:13 pm Indan Zupancic wrote:
On Thu, September 20, 2007 22:38, Rob Landley wrote:
I've been playing with an idea for a while to improve the printk()
situation, but it's a more intrusive change than I've had time to bang
on.
Right now, the first argument
On Fri, September 21, 2007 01:18, Rob Landley wrote:
On Thursday 20 September 2007 4:26:13 pm Indan Zupancic wrote:
A quick scroll through a vmlinux binary shows that there are quite a
lot areas consisting only of some repeated pattern. Mostly 0x00, but
also 0x90 and .GCC: (GNU) 4.2.1..
On Thursday 20 September 2007 5:14:25 pm Joe Perches wrote:
On Thu, 2007-09-20 at 14:58 -0700, Tim Bird wrote:
Given that there are about 60,000 printks in the kernel (and that's
not counting wrappers like dprintk() and other locally-defined
functions and macros) it would be a huge task to
On Thu, 2007-09-20 at 19:28 -0500, Rob Landley wrote:
You convert printk(KERN_INFO, blah) to pr_INFO(blah)?
more or less.
printk(KERN_INFO foo) to pr_info(foo)
printk(KERN_EMERG foo) to pr_emerge(foo)
etc.
I'm not finding pr_INFO with a grep on the files in
2.6.23-rc7.
I haven't submitted
* Thu, 20 Sep 2007 15:15:47 -0700
* X-MimeOLE: Produced By Microsoft Exchange V6.5
[]
*Shrug*.
My problem is that switching off printk is the single biggest bloat
cutter
in
the kernel, yet it makes the resulting system very hard to support. It
combines a big upside with a big downside, and I'd
Tim Bird wrote:
> [EMAIL PROTECTED] wrote:
>
>> Is anybody working on testing that the patchkit "does no harm" for bigger
>> boxes (laptops, desktops, servers)?
>>
> Not to my knowledge. Most of the things it provides are
> only activated by config options. So my sense is that just
>
Tim Bird wrote:
> Andrew Morton wrote:
>
>> On Wed, 19 Sep 2007 11:03:09 -0700
>> Tim Bird <[EMAIL PROTECTED]> wrote:
>>
>>
>>> Recently, the CE Linux forum has been working to revive the
>>> Linux-tiny project. At OLS, I asked for interested parties
>>> to volunteer to become the new
Andrew Morton wrote:
> On Wed, 19 Sep 2007 11:03:09 -0700
> Tim Bird <[EMAIL PROTECTED]> wrote:
>
>> Recently, the CE Linux forum has been working to revive the
>> Linux-tiny project. At OLS, I asked for interested parties
>> to volunteer to become the new maintainer for the Linux-tiny patchset.
[EMAIL PROTECTED] wrote:
> On Wed, 19 Sep 2007 12:41:08 PDT, Tim Bird said:
>> The patchkit gives a place for things to live while they are out
>> of mainline, and still have multiple people use and work on them.
>
> Is anybody working on testing that the patchkit "does no harm" for bigger
>
On Wed, 19 Sep 2007 11:03:09 -0700
Tim Bird <[EMAIL PROTECTED]> wrote:
> Recently, the CE Linux forum has been working to revive the
> Linux-tiny project. At OLS, I asked for interested parties
> to volunteer to become the new maintainer for the Linux-tiny patchset.
I volunteer! Send patches
On Wed, 19 Sep 2007 12:41:08 PDT, Tim Bird said:
> The patchkit gives a place for things to live while they are out
> of mainline, and still have multiple people use and work on them.
Is anybody working on testing that the patchkit "does no harm" for bigger
boxes (laptops, desktops, servers)?
Andi Kleen wrote:
> Tim Bird <[EMAIL PROTECTED]> writes:
>
>
>> Recently, the CE Linux forum has been working to revive the
>> Linux-tiny project. At OLS, I asked for interested parties
>> to volunteer to become the new maintainer for the Linux-tiny patchset.
>
> Not sure what the point is of a
Luis R. Rodriguez wrote:
> Will there be a separate git for testing?
Right now we're publishing a quilt-able tarball.
Instructions for applying this are on the
http://elinux.org/Linux_Tiny page.
Note that some broken patches are kept around
in the patches/tiny directory, but commented
out in the
Tim Bird <[EMAIL PROTECTED]> writes:
> Recently, the CE Linux forum has been working to revive the
> Linux-tiny project. At OLS, I asked for interested parties
> to volunteer to become the new maintainer for the Linux-tiny patchset.
Not sure what the point is of a separate patchkit. If it's a
On 9/19/07, Tim Bird <[EMAIL PROTECTED]> wrote:
> Recently, the CE Linux forum has been working to revive the
> Linux-tiny project. At OLS, I asked for interested parties
> to volunteer to become the new maintainer for the Linux-tiny patchset.
>
> A few candidates came forward, but eventually
1 - 100 of 114 matches
Mail list logo
