Re: [RFC/PATCH] Documentation of kernel messages
From: Jan Kara
Date: Thu Jun 14 2007 - 08:13:53 EST
On Thu 14-06-07 13:47:41, holzheu wrote:
> On Thu, 2007-06-14 at 12:38 +0200, holzheu wrote:
> > On Thu, 2007-06-14 at 11:41 +0200, Jan Kara wrote:
> > > <snip>
> > >
> > > > Your proposal is similar to one I made to some Japanese developers
> > > > earlier this year. I was more modest, proposing that we
> > > >
> > > > - add an enhanced printk
> > > >
> > > > xxprintk(msgid, KERN_ERR "some text %d\n", some_number);
> > > Maybe a stupid idea but why do we want to assign these numbers by hand?
> > > I can imagine it could introduce collisions when merging tons of patches
> > > with new messages... Wouldn't it be better to compute say, 8-byte hash
> > > from the message and use it as it's identifier? We could do this
> > > automagically at compile time.
> >
> > Of course automatically generated message numbers would be great and
> > something like:
> >
> > hub.4a5bcd77: Detected some problem.
>
> Sorry, I first read: 8 characters not 8 bytes.
>
> Indeed, "hub.d41d8cd98f00b204: Detected some problem." ... does not look
> like very beautiful.
>
> But maybe also 4 bytes would be enough, since the hash only has to be
> unique within one component e.g. "hub".
It depends how large components you expect. For example for 10000
messages there is already 1% probability of collision so it means sooner or
later we are going to hit it... For 1000 messages the probability is
roughly 0.1% which is still not so small that I'd be comfortable with it.
On the other hand we could use something like gperf to generate perfect
hashing function and then we don't have to worry about colisions.
Honza
--
Jan Kara <jack@xxxxxxx>
SuSE CR Labs
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/