From: Rob Landley <rob@landley.net>
To: Randy Dunlap <randy.dunlap@oracle.com>
Cc: Vegard Nossum <vegard.nossum@gmail.com>,
LKML <linux-kernel@vger.kernel.org>,
Kyle Moffett <mrmacman_g4@mac.com>,
Michael Holzheu <holzheu@linux.vnet.ibm.com>,
Joe Perches <joe@perches.com>,
Dick Streefland <dick.streefland@altium.nl>,
Geert Uytterhoeven <Geert.Uytterhoeven@sonycom.com>,
Jesse Barnes <jesse.barnes@intel.com>,
Arnd Bergmann <arnd@arndb.de>,
Jan Engelhardt <jengelh@computergmbh.de>,
Emil Medve <Emilian.Medve@freescale.com>,
Stephen Hemminger <shemminger@linux-foundation.org>,
"linux@horizon.com" <linux@horizon.com>,
Miguel Ojeda <maxextreme@gmail.com>
Subject: Re: [RFC][PATCH] New message-logging API (kprint)
Date: Thu, 4 Oct 2007 20:59:25 -0500 [thread overview]
Message-ID: <200710042059.25721.rob@landley.net> (raw)
In-Reply-To: <20071004131703.25046db9.randy.dunlap@oracle.com>
On Thursday 04 October 2007 3:17:03 pm Randy Dunlap wrote:
> On Thu, 04 Oct 2007 22:04:07 +0200 Vegard Nossum wrote:
> > Description: This patch largely implements the kprint API as previously
> > posted to the LKML and described in Documentation/kprint.txt (see patch).
> >
> > The main purpose of this change is provide a unified logging API to the
> > kernel and at the same time make it easy to add extensions, now and
> > later.
> >
> > My changes and additions are as follows:
>
> $ diffstat -p1 -w70 kprint.patch
...
> 40 files changed, 1660 insertions(+), 72 deletions(-)
I started this thread by posting an idea I had for shrinking the kernel by
allowing more code to be configured out. The API change was exactly one new
parameter, with a direct 1->1 mapping from the old API to the new one, which
was trivial to convert and which the compiler would catch if you missed one.
The result of the discussion is a patch adding 1600 lines to the kernel,
without removing anything.
Last I checked, the current prink() worked just fine. Why is this _not_ the
dreaded "infrastructure in search of a use"? What exactly can we _not_ do
with the current code? What does this allow us to remove and simplify?
I'm confused about what people are trying to accomplish here...
Rob
--
"One of my most productive days was throwing away 1000 lines of code."
- Ken Thompson.
next prev parent reply other threads:[~2007-10-05 1:59 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-10-04 20:04 [RFC][PATCH] New message-logging API (kprint) Vegard Nossum
2007-10-04 20:17 ` Randy Dunlap
2007-10-05 1:59 ` Rob Landley [this message]
2007-10-05 7:01 ` Miguel Ojeda
2007-10-05 16:26 ` Rob Landley
2007-10-05 23:01 ` Miguel Ojeda
2007-10-06 0:34 ` Stephen Hemminger
2007-10-07 10:20 ` Miguel Ojeda
2007-10-07 21:56 ` Rob Landley
2007-10-07 22:32 ` Randy Dunlap
2007-10-06 6:10 ` Vegard Nossum
2007-10-07 21:50 ` Rob Landley
2007-10-08 15:25 ` Stephen Hemminger
2007-10-08 15:33 ` Vegard Nossum
2007-10-08 15:42 ` Stephen Hemminger
2007-10-05 13:13 ` Vegard Nossum
2007-10-05 16:05 ` Rob Landley
2007-10-05 17:01 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200710042059.25721.rob@landley.net \
--to=rob@landley.net \
--cc=Emilian.Medve@freescale.com \
--cc=Geert.Uytterhoeven@sonycom.com \
--cc=arnd@arndb.de \
--cc=dick.streefland@altium.nl \
--cc=holzheu@linux.vnet.ibm.com \
--cc=jengelh@computergmbh.de \
--cc=jesse.barnes@intel.com \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux@horizon.com \
--cc=maxextreme@gmail.com \
--cc=mrmacman_g4@mac.com \
--cc=randy.dunlap@oracle.com \
--cc=shemminger@linux-foundation.org \
--cc=vegard.nossum@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.