Message-ID: <653402b90710051601x347924d3j34b5ec740c39e81c@mail.gmail.com>
Date:	Sat, 6 Oct 2007 01:01:10 +0200
From:	"Miguel Ojeda" <maxextreme@...il.com>
To:	"Rob Landley" <rob@...dley.net>
Cc:	"Randy Dunlap" <randy.dunlap@...cle.com>,
	"Vegard Nossum" <vegard.nossum@...il.com>,
	LKML <linux-kernel@...r.kernel.org>,
	"Kyle Moffett" <mrmacman_g4@....com>,
	"Michael Holzheu" <holzheu@...ux.vnet.ibm.com>,
	"Joe Perches" <joe@...ches.com>,
	"Dick Streefland" <dick.streefland@...ium.nl>,
	"Geert Uytterhoeven" <Geert.Uytterhoeven@...ycom.com>,
	"Jesse Barnes" <jesse.barnes@...el.com>,
	"Arnd Bergmann" <arnd@...db.de>,
	"Jan Engelhardt" <jengelh@...putergmbh.de>,
	"Emil Medve" <Emilian.Medve@...escale.com>,
	"Stephen Hemminger" <shemminger@...ux-foundation.org>,
	"linux@...izon.com" <linux@...izon.com>
Subject: Re: [RFC][PATCH] New message-logging API (kprint)

On 10/5/07, Rob Landley <rob@...dley.net> wrote:
> On Friday 05 October 2007 2:01:08 am Miguel Ojeda wrote:
> >
> > I think we all are trying to give ideas to improve the current logging API.
> >
> > If something works, it's great; but it doesn't mean that it can't be
> > improved, right?
>
> I'm all for improving the kernel, but my definition of "improved" does not
> include every possible change.  I balance "smaller and simpler" with "more
> features".  Complexity is a cost, we should get something in return.
>
> Making the same functionality simpler makes it "cheaper" from a development
> standpoint.  Smaller and simpler means less overhead, less to understand,
> less to go wrong.  It's also attractive to me personally, because I am a Bear
> of Very Little Brain and between the dozen or so projects I try to follow, I
> have trouble fitting all the details in my head when they're tricky or they
> change ever time I look at them.  (Especially when I get distracted from one
> of those projects for 3-6 months and come back to find it changed.)

I fully agree. However, I just gave away some ideas that I believe
they can make printk() easier and more understandable than it is right
now (for example, standardizing kprint_[registered,detected,...]
messages is something that I think it can simplify everyday use of
messages, both to people who has to code it, review/search the code
and people that reads the kernel output).

>
> I recognize constantly having to learn new things as part of the cost of
> living, and making things more complicated happens as you add features.  But
> when somebody reinvents the wheel it's really nice to have clearly spelled
> out the advantages of the new wheel vs the old one.  It's nice for there to
> _be_ clear advantages, offsetting the increased complexity cost.

I got your point, and I agree. However, I also see the possibilities
that a change of the logging API can bring: If someday it gets
improved, maybe such day should be improved as far as possible. This
kind of stuff that affect so many things are not going to change for
long periods of time, as you said.

Still, I know some kind of changes can be really complex and maybe are
unproductive. I think the point is to get a middle point between new
complexity vs. new features.

>
> In this case, upon asking, the only potential advantage here seems to be "now
> we can translate dmesg output into Chinese more easily", which is something

Well, other improvements suggested are not just about internationalization.

> you could already do in userspace already via regular expressions in a
> translating dmesg, and which has the primary effect of making the resulting
> dmesg useless to report to lkml without really improving the amount of sense
> it makes to nontechnical end users (who really aren't the target of the
> english dmesg output, either).  The "linux developer who can't read english"
> niche is inherently somewhat problematic, as has been discussed here before.
>

I didn't talk about internationalization (in fact, I think it is going
to be pretty complex to get it right and, worse, to get it up-to-date
in each release without error in translations)

> The cost of this patch is making the kernel bigger, the in-kernel printk api
> more complicated, and the userspace dmesg noticeably more complex just to
> implement the same functionality against the new API.  Documenting the
> changes is nice, but doesn't reduce this increase in complexity.
>
> The original idea (selectively compile out printk() instances based on log
> level to conserve space) is explicitly not addressed by this patch, and in
> fact this patch might actually make it harder to implement (by complicating
> the code).
>
> *shrug*  That doesn't mean my objections are important to anyone else, just
> that I don't personally see any reason to be enthusiastic about this patch.

Take a look to other suggested changes, maybe you like some of them
and you will have found a reason to be enthusiastic :)

>
> Rob

-- 
Miguel Ojeda
http://maxextreme.googlepages.com/index.htm
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists