Date: Fri, 1 Apr 2005 12:46:30 -0800
From: Matt Mackall <mpm@selenic.com>
To: Andrew Morton <akpm@osdl.org>
Cc: linux-kernel@vger.kernel.org
Subject: Re: [PATCH] clean up kernel messages
Message-ID: <20050401204629.GJ15453@waste.org>
References: <20050401200851.GG15453@waste.org> <20050401122641.7c52eaab.akpm@osdl.org>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20050401122641.7c52eaab.akpm@osdl.org>
User-Agent: Mutt/1.5.6+20040907i
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2018
Lines: 58

On Fri, Apr 01, 2005 at 12:26:41PM -0800, Andrew Morton wrote:
> Matt Mackall <mpm@selenic.com> wrote:
> >
> > This patch tidies up those annoying kernel messages. A typical kernel
> >  boot now looks like this:
> > 
> >  Loading Linux... Uncompressing kernel...
> >  #
> > 
> >  See? Much nicer. This patch saves about 375k on my laptop config and
> >  nearly 100k on minimal configs.
> > 
> 
> heh.  Please take a look at
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0004.2/0709.html, see if
> Graham did anything which you missed.

He's got a bunch of stuff that's not strictly related in there and
stuff I've already dealt with (vprintk and the like) and stuff that's
still forthcoming (panic tweaks, etc.). I also leave in all the APIs
like dmesg, they just no longer do anything.

> One problem was that
> 
> 	printk("foo");
> 
> will still cause the string "foo\0" to appear in the kernel image.  That
> was fixed in later gcc's, but it would be interesting to know which
> compilers get it right.

Haven't encountered this. I think it should be fine for any compiler
that can handle 2.6. This has been in -tiny for nearly a year and a
half and no one's complained.
 
> >  +static inline int printk(const char *s, ...) { return 0; }
> 
> Actually printk() is supposed to return the number of chars which it
> printed.  So if someone is doing:
> 
> 	while (len < 40)
> 		len += printk("something");
> 
> you've gone and made them lock up.
> 
> But I think the number of places where we examine the printk return value
> is near zero.

Well in some sense 0 is the proper return but I suppose this could be
made to return 1. Small enough not break anything, big enough so that
things like the above get unstuck.

-- 
Mathematics is the supreme nostalgia of our time.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/