mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Vegard Nossum" <vegard.nossum@gmail.com>
To: "Joe Perches" <joe@perches.com>
Cc: linux@horizon.com, linux-kernel@vger.kernel.org,
	"Miguel Ojeda" <maxextreme@gmail.com>
Subject: Re: [RFC] New kernel-message logging API
Date: Tue, 25 Sep 2007 10:06:35 +0200	[thread overview]
Message-ID: <19f34abd0709250106n6540539ap764dfaa23958ab81@mail.gmail.com> (raw)
In-Reply-To: <1190703254.3964.11.camel@localhost>

On 9/25/07, Joe Perches <joe@perches.com> wrote:
> On Tue, 2007-09-25 at 00:58 -0400, linux@horizon.com wrote:
> > Even the "kp_" prefix is actually pretty unnecessary.  It's "info"
> > and a human-readable string that make it recognizable as a log message.
>
> While I agree a prefix isn't necessary, info, warn, err
> are already frequently #define'd and used.
>
> kp_<level> isn't currently in use.
>
> $ egrep -r -l --include=*.[ch] "^[[:space:]]*#[[:space:]]*define[[:space:]]+(info|err|warn)\b" * | wc -l
> 29

Yes, this is a very good point, they're already used. If they hadn't
been, everything would have been perfect. Actually, I'd have preferred
info/warn/err over kprint_<level> if it wasn't for the fact that
they're used (and in slightly different ways too).

As I wrote initially, one of the absolute requirements of a new API is
to retain full backwards compatibility with printk(). Which means that
using simply err()/info()/warn() is out of the question *for now*.
That is not to say we can't change this at a later time.

I think it would be good to have a base layer containing the functions
kprint_<level>(), just to have something that 1) has a meaningful
name, and 2) doesn't disturb anybody else's names. err/info/warn or
kp_err/info/warn() (in order to have shorter names) can then be
implemented in terms of this.

I suppose that another goal of a new API would be to unify the
somewhat-a-mess of API that is now, i.e. many alternatives that do the
same thing is also not good. But this can be changed with patches (to
convert to new API) later.

If you look closer at the current definitions of erro/warn/info, it
turns out that most of them also do this to automatically prefix all
messages with the driver name. This makes me realize that there really
is a need for a way to automatically prefix messages or store a
per-message "subsystem" field. I propose the following solution:

The kprint.h header file looks like this:

/* This is a back-up string to be used if the source file doesn't
define this as a macro. */
const char *SUBSYSTEM = "";

/* Call this macro whatever you want, it's just an example anyway. */
#define info(msg, ...) printf("%s: " msg, SUBSYSTEM, ## __VA_ARGS__)

Then you can have a C file that overrides SUBSYSTEM by defining it as a macro:
#include <linux/kprint.h>
#define SUBSYSTEM "usb"
info("test");
--> results in printf("%s: " "test", "usb");

Or, a C file that doesn't:
#include <linux/kprint.h>
info("test");
--> results in printf("%s: " "test", SYBSYSTEM);
--> output is ": test"


Though, instead of actually incorporating this SUBSYSTEM name into the
string, I suggest passing it off as an argument into the real kprint()
machinery, to be stored along (but seperately) with timestamp, etc.

Hm, that's a digression. But thanks for the idea :)


Vegard

  parent reply	other threads:[~2007-09-25  8:06 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-09-25  4:58 linux
2007-09-25  6:54 ` Joe Perches
2007-09-25  7:50   ` linux
2007-09-25  8:06   ` Vegard Nossum [this message]
  -- strict thread matches above, loose matches on Subject: below --
2007-09-22 19:27 Vegard Nossum
2007-09-23  0:13 ` Joe Perches
2007-09-23  0:40   ` Kyle Moffett
2007-09-23  0:47     ` Joe Perches
2007-09-23  3:43       ` Kyle Moffett
2007-09-23  8:39   ` Vegard Nossum
2007-09-23  8:45     ` Jan Engelhardt
2007-09-23  9:20       ` Vegard Nossum
2007-09-23  9:38         ` Jan Engelhardt
2007-09-23 19:23       ` Joe Perches
2007-09-23 19:25     ` Joe Perches
2007-09-23  1:05 ` Miguel Ojeda
2007-09-25  5:27   ` Vegard Nossum
2007-09-25 17:24     ` Miguel Ojeda
2007-09-23 20:05 ` Rob Landley
2007-09-24  9:22 ` Michael Holzheu
2007-09-24 15:19   ` Joe Perches
2007-09-24 16:43     ` Vegard Nossum
2007-09-24 17:00       ` Joe Perches
2007-09-24 20:37         ` Vegard Nossum
2007-09-25  1:18           ` Rob Landley
2007-09-24 23:51     ` Rob Landley
2007-09-25  0:10       ` Joe Perches
2007-09-25  1:46         ` Rob Landley
2007-09-25  8:57     ` Michael Holzheu
2007-09-24 18:26 ` Jesse Barnes

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=19f34abd0709250106n6540539ap764dfaa23958ab81@mail.gmail.com \
    --to=vegard.nossum@gmail.com \
    --cc=joe@perches.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux@horizon.com \
    --cc=maxextreme@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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®