linux-kernel - Re: [RFC/PATCH] Documentation of kernel messages

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <E1HzHSA-0006Dg-3a@w-gerrit.beaverton.ibm.com>
Date:	Fri, 15 Jun 2007 12:27:25 -0700
From:	Gerrit Huizenga <gh@...ibm.com>
To:	Randy Dunlap <randy.dunlap@...cle.com>
cc:	holzheu@...ux.vnet.ibm.com, Jan Kara <jack@...e.cz>,
	Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, gregkh@...e.de, mtk-manpages@....net,
	schwidefsky@...ibm.com, heiko.carstens@...ibm.com,
	"lf_kernel_messages@...ux-foundation.org" 
	<lf_kernel_messages@...ux-foundation.org>
Subject: Re: [RFC/PATCH] Documentation of kernel messages 

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" doesn't cut it IMO.
> 
> -- 
> ~Randy

Fair point, Randy.

This came up this time because people in Japan supporting Linux customers
are not always familiar with Linux kernel internals and thus debugging
problems based on a terse, English language message is just painful.  Also,
any given message doesn't really provide any input about what *really*
failed, what should be done about it, how to correct this issue, or what
parts to pull out of your machine and replace with properly working parts.

So, the Message Pedia is basically a Japanese language wiki today where
people doing support can annotate the messages with real life experience on
what to *do* about the error.

Part of the problem is that the error messages when extracted don't
stand alone and don't easily allow tracing back to the real source.  When
the problem is handed from the second line support folks deeper into the
support or development organization, the message has to be found in the
source tree in some non-ambiguous fashion.

The other problem that comes up in other, non-English locales is that
debugging your Linux box when you are a non-native English speaker is
just plain impossible.  Providing a means for getting localized kernel
messages allows more end users to at least reasonably debug their own
machine.  Most every user level project today allows localization directly
but the kernel has never had any reasonable mechanism for localisation.

Now, the proposal here doesn't make the kernel "as good as" user level
application, but it would at least provide a searchable key to help
people get localized guidance on problems.

I'm sure there are other benefits that most can see based on just simple
debuggability.  But the Japanese goal is really to construct a database
of debugging info & context based on their experiences.

And, I'm sure that others can speak for themselves.  I'm mostly playing
scribe on this one - we abandoned our error and event subsystem work years
ago, even though this was one of the biggest weaknesses we saw in customer
support 3-5 years ago, simply because our changes were still viewed as
too invasive for mainline kernel.  These proposed changes help a lot, while
remaining almost completely invisible to most developers.

gerrit
-
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/