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
> contin
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 t
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 fla
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 th
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 g
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 (includi
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 t
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 remot
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 f
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 y
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 fol
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 pr
>> >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(), an
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 (an
> >[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 __F
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 kee
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
>>>i
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
- 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 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 forwa
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
* 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 downsi
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
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 ta
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 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 firs
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
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:
> > #defin
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 concatena
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 vag
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 some
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,
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(l
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
> strin
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 event
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
> app
[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
> boxes
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)? Tha
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 se
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 r
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 Mich
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 Mich
51 matches
Mail list logo
