On Tue, 2007-06-19 at 10:51 +0200, holzheu wrote:
> On Mon, 2007-06-18 at 18:36 -0700, Arjan van de Ven wrote:
> > On Mon, 2007-06-18 at 15:53 +0200, holzheu wrote:
> > > On Mon, 2007-06-18 at 06:12 -0700, Arjan van de Ven wrote:
> > > > On Mon, 2007-06-18 at 14:55 +0200, holzheu wrote:
> > > > > H
On Mon, 2007-06-18 at 18:36 -0700, Arjan van de Ven wrote:
> well surely the messages are caught by some userspace program,
> right? (like syslog).. that can do the lookup and make it all
> conveniently lookup-able and cross-referencable etc etc
Ok, I agree. Maybe that's really a good i
On Mon, 2007-06-18 at 18:36 -0700, Arjan van de Ven wrote:
> On Mon, 2007-06-18 at 15:53 +0200, holzheu wrote:
> > On Mon, 2007-06-18 at 06:12 -0700, Arjan van de Ven wrote:
> > > On Mon, 2007-06-18 at 14:55 +0200, holzheu wrote:
> > > > Hi Gerrit,
> > > >
> > > > The common thing of your and our
Hi Michael,
I initiated this discussion in The Linux Foundation [EMAIL PROTECTED] Campus
last week from the viewpoint of requirements by Japanese vendors/users.
As for a file to store message descriptions, I perfectly agree with your
analysis and we also noticed some (+) and (-) you pointed out i
On Mon, 18 Jun 2007 17:13:19 PDT, Tim Bird wrote:
> Gerrit Huizenga wrote:
> > Further, yet another kernel config option could allow distros to output
> > the calculated MD5 sum to be printed, much like we do with timestamps
> > today.
>
> > Comments?
>
> Would the compiled-in text then also bec
On Mon, 2007-06-18 at 15:53 +0200, holzheu wrote:
> On Mon, 2007-06-18 at 06:12 -0700, Arjan van de Ven wrote:
> > On Mon, 2007-06-18 at 14:55 +0200, holzheu wrote:
> > > Hi Gerrit,
> > >
> > > The common thing of your and our approach is, that we need an ID to
> > > identify a message either by:
Gerrit Huizenga wrote:
> Further, yet another kernel config option could allow distros to output
> the calculated MD5 sum to be printed, much like we do with timestamps
> today.
> Comments?
Would the compiled-in text then also become replaceable?
Or is the MD5 sum output expected to be in additio
On Mon, 18 Jun 2007 15:11:57 +0200 Sam Ravnborg wrote:
> On Fri, Jun 15, 2007 at 11:42:15AM -0700, Gerrit Huizenga wrote:
> >
> > Andrew mentioned a mechanism for adding a subsystem tag or other tag
> > which helps disambiguate the message, either in the message file or in
> > the end user docume
Hi!
> > 'lp%d: on fire' -> 'your printer failed basic tests, you should check
> > cabling'.
>
> Hmmm... What about extracting all format strings from the KMSG_DOC
> macros and storing them in a file. E.g.:
>
> printk("lp%d: on fire");
>
> /**
>* message
>*
>* Description:
>*
On Mon, 2007-06-18 at 06:12 -0700, Arjan van de Ven wrote:
> On Mon, 2007-06-18 at 14:55 +0200, holzheu wrote:
> > Hi Gerrit,
> >
> > The common thing of your and our approach is, that we need an ID to
> > identify a message either by:
>
>
> Maybe I am missing something big, but why is an ID nee
Hi Pavel,
On Fri, 2007-06-15 at 12:40 +, Pavel Machek wrote:
> Hi!
>
> > > 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
On Mon 18-06-07 06:12:54, Arjan van de Ven wrote:
> On Mon, 2007-06-18 at 14:55 +0200, holzheu wrote:
> > Hi Gerrit,
> >
> > The common thing of your and our approach is, that we need an ID to
> > identify a message either by:
>
>
> Maybe I am missing something big, but why is an ID needed?
> Th
On Mon, 2007-06-18 at 14:55 +0200, holzheu wrote:
> Hi Gerrit,
>
> The common thing of your and our approach is, that we need an ID to
> identify a message either by:
Maybe I am missing something big, but why is an ID needed?
The message IS the ID right? That's the only thing that is robust
agai
On Fri, Jun 15, 2007 at 11:42:15AM -0700, Gerrit Huizenga wrote:
>
> Andrew mentioned a mechanism for adding a subsystem tag or other tag
> which helps disambiguate the message, either in the message file or in
> the end user documentation (e.g. the Message Pedia/mPedia that the Japanese
> have al
Hi Gerrit,
The common thing of your and our approach is, that we need an ID to
identify a message either by:
* Using hashes + component name (maybe)
* Or using hand-made message numbers + component name. Numbers have
to be unique within the kernel component
I think the main difference of your
On Fri, 15 Jun 2007 11:51:51 PDT, Randy Dunlap wrote:
>
> For those of us who have not been in on these meetings, I think that
> some serious justifications are needed. The last paragraph began to
> go in that direction, but it needs to be more detailed and convincing.
> And "for debugging" does
On Fri, Jun 15, 2007 at 11:51:51AM -0700, Randy Dunlap wrote:
> Gerrit Huizenga wrote:
> > On Thu, 14 Jun 2007 12:38:53 +0200, holzheu wrote:
> >> On Thu, 2007-06-14 at 11:41 +0200, Jan Kara wrote:
> >>>
> >>>
> Your proposal is similar to one I made to some Japanese developers
> earl
Gerrit Huizenga wrote:
On Thu, 14 Jun 2007 12:38:53 +0200, holzheu wrote:
On Thu, 2007-06-14 at 11:41 +0200, Jan Kara wrote:
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
xxprin
On Thu, 14 Jun 2007 12:38:53 +0200, holzheu wrote:
> On Thu, 2007-06-14 at 11:41 +0200, Jan Kara wrote:
> >
> >
> > > 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
> > >
>
Hi!
> > 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
On Jun 13 2007 12:04, Joe Perches wrote:
>On Wed, 2007-06-13 at 20:18 +0200, holzheu wrote:
>> But they unfortunately do not solve our problem. We need an identifier
>> for a documented message in order to find the right description for a
>> message.
>
>I believe it better to simply add __FILE__ &
On Jun 13 2007 12:50, [EMAIL PROTECTED] wrote:
>> In general we think, that also for Linux it is a good thing to have
>> documentation for the most important kernel/driver messages. Even
>> kernel hackers not always are aware of the meaning of kernel messages
>> for components, which they don't kn
On Thu, 2007-06-14 at 14:26 +0200, Jan Kara wrote:
> > 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 1
> messages there is already 1% probability of collision s
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:
> > >
> > >
> > > > Your proposal is similar to one I made to some Japanese developers
> > > > earlier this year. I was more modest, proposing tha
On Thu, 2007-06-14 at 12:38 +0200, holzheu wrote:
> On Thu, 2007-06-14 at 11:41 +0200, Jan Kara wrote:
> >
> >
> > > 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
> > >
> >
On Thu, 2007-06-14 at 11:41 +0200, Jan Kara wrote:
>
>
> > 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);
>
> 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 h
Hi,
holzheu <[EMAIL PROTECTED]> writes:
> If the information is to big for the printk itself, because you would
> need 10 lines to explain what happened, wouldn't it be good to have a
> place where to put that information?
I think if a message really has to be 10 lines long to be clear then
it s
On Wed, 2007-06-13 at 11:15 -0700, Andrew Morton wrote:
> Your proposal is similar to one I made to some Japanese developers
> earlier this year.
Interesting. Our requirement comes from Japan as well.
> I was more modest, proposing that we
>
> - add an enhanced printk
>
> xxprintk(ms
On Wed, 2007-06-13 at 11:32 -0700, Greg KH wrote:
> > > So, why not use what we already have and work off of it?
> >
> > dev_printk() and friends are great, since they already define
> something
> > like KMSG_COMPONENT: The driver name.
>
> They provide way more than that, they also provide the e
[EMAIL PROTECTED] wrote:
> On Wed, 13 Jun 2007 12:04:56 PDT, Joe Perches said:
>
>> I believe it better to simply add __FILE__ & __LINE__ to the
>> macro rather than some other externally specified unique
>> identifier that adds developer overhead and easily gets stale.
>
> There's been plenty of
On Wed, 13 Jun 2007 12:04:56 PDT, Joe Perches said:
> I believe it better to simply add __FILE__ & __LINE__ to the
> macro rather than some other externally specified unique
> identifier that adds developer overhead and easily gets stale.
There's been plenty of times I've wished for that. Now if
On Wed, 2007-06-13 at 20:18 +0200, holzheu wrote:
> But they unfortunately do not solve our problem. We need an identifier
> for a documented message in order to find the right description for a
> message.
I believe it better to simply add __FILE__ & __LINE__ to the
macro rather than some other ex
Greg KH wrote:
On Wed, Jun 13, 2007 at 08:18:00PM +0200, holzheu wrote:
Hi Greg,
Ick, why are you ignoring what we have already with dev_printk() and
friends? We are just finally getting developers to use that, I think it
will be almost impossible to get people to change to something else,
es
On Wed, 2007-06-13 at 11:32 -0700, Greg KH wrote:
>
> > dev_printk() and friends are great, since they already define
> something
> > like KMSG_COMPONENT: The driver name.
>
> They provide way more than that, they also provide the explicit device
> that is being discussed, as well as other things
On Wed, 2007-06-13 at 11:23 -0700, David Miller wrote:
> I think my general response to something like this, if it goes
> in, would be to stop emitting useful kernel log messages
> in the code I write because having to document it too on top
> of that is just too much extra work to be worthwhile.
On Wed, Jun 13, 2007 at 08:18:00PM +0200, holzheu wrote:
> Hi Greg,
>
> > Ick, why are you ignoring what we have already with dev_printk() and
> > friends? We are just finally getting developers to use that, I think it
> > will be almost impossible to get people to change to something else,
> > e
I think my general response to something like this, if it goes
in, would be to stop emitting useful kernel log messages
in the code I write because having to document it too on top
of that is just too much extra work to be worthwhile.
-
To unsubscribe from this list: send the line "unsubscribe lin
Hi Greg,
> Ick, why are you ignoring what we have already with dev_printk() and
> friends? We are just finally getting developers to use that, I think it
> will be almost impossible to get people to change to something else,
> especially one that isn't even as "correct" as what dev_printk() offer
> On Wed, 13 Jun 2007 17:06:57 +0200 holzheu <[EMAIL PROTECTED]> wrote:
> Greetings,
>
> The operation of a Linux system sometimes requires to decode the
> meaning of a specific kernel message, e.g. an error message of a
> driver. Especially on our mainframe zSeries platform system
> administrator
Hi Valdis,
On Wed, 2007-06-13 at 12:50 -0400, [EMAIL PROTECTED] wrote:
> On Wed, 13 Jun 2007 17:06:57 +0200, holzheu said:
> > They are used to that, because all other operating systems on that
> > platform like z/OS, z/VM or z/VSE have message catalogs with detailed
> > descriptions about the se
On Wednesday 13 June 2007 12:50:55 [EMAIL PROTECTED] wrote:
> > In general we think, that also for Linux it is a good thing to have
> > documentation for the most important kernel/driver messages. Even
> > kernel hackers not always are aware of the meaning of kernel messages
> > for components, whi
On Wed, Jun 13, 2007 at 05:06:57PM +0200, holzheu wrote:
> Current prototype implementation:
> =
>
> The structure of a kernel message is: .:
>
> * component: Name of the kernel or driver component e.g. "pci", "ide",
> etc.
> * msg number: Within the component
On Wed, 2007-06-13 at 21:16 +0400, Alexey Dobriyan wrote:
> On Wed, Jun 13, 2007 at 05:06:57PM +0200, holzheu wrote:
> > -CHECK = sparse
> > -
> > -CHECKFLAGS := -D__linux__ -Dlinux -D__STDC__ -Dunix -D__unix__
> > -Wbitwise $(CF)
> > +CHECK = scripts/kmsg-doc check
>
Hi Dave,
On Wed, 2007-06-13 at 09:37 -0700, Dave Hansen wrote:
[snip]
> I'm not sure we want to make Linux more like z/* in this regard. :)
>
> The problem with your proposal is that every time a new message in the
> kernel is created or modified, you need somebody to go update that
> documenta
On Wed, Jun 13, 2007 at 09:37:29AM -0700, Dave Hansen wrote:
> On Wed, 2007-06-13 at 17:06 +0200, holzheu wrote:
> > The operation of a Linux system sometimes requires to decode the
> > meaning of a specific kernel message, e.g. an error message of a
> > driver. Especially on our mainframe zSeries
On Wed, Jun 13, 2007 at 05:06:57PM +0200, holzheu wrote:
> -CHECK= sparse
> -
> -CHECKFLAGS := -D__linux__ -Dlinux -D__STDC__ -Dunix -D__unix__ -Wbitwise
> $(CF)
> +CHECK= scripts/kmsg-doc check
> +CHECKFLAGS =
Ick. Don't touch those checking kernel with spar
On Wed, 13 Jun 2007 17:06:57 +0200, holzheu said:
> They are used to that, because all other operating systems on that
> platform like z/OS, z/VM or z/VSE have message catalogs with detailed
> descriptions about the semantics of the messages.
25 years ago, I did OS/MVT and OS/VS1 for a living, so
On Wed, 2007-06-13 at 17:06 +0200, holzheu wrote:
> The operation of a Linux system sometimes requires to decode the
> meaning of a specific kernel message, e.g. an error message of a
> driver. Especially on our mainframe zSeries platform system
> administrators want to have descriptions for Linux
Greetings,
The operation of a Linux system sometimes requires to decode the
meaning of a specific kernel message, e.g. an error message of a
driver. Especially on our mainframe zSeries platform system
administrators want to have descriptions for Linux kernel messages.
They are used to that, becaus
50 matches
Mail list logo
