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: <1182171354.11400.40.camel@localhost.localdomain>
Date:	Mon, 18 Jun 2007 14:55:54 +0200
From:	holzheu <holzheu@...ux.vnet.ibm.com>
To:	Gerrit Huizenga <gh@...ibm.com>
Cc:	Jan Kara <jack@...e.cz>, Andrew Morton <akpm@...ux-foundation.org>,
	linux-kernel@...r.kernel.org, randy.dunlap@...cle.com,
	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

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 approach is, that documentation will
be maintained outside the kernel. This has advantages, but also
disadvantages:

(+) Developers have less work to do :-)
(+) Kernel sources and patches have less lines of code, since message
    descriptions are not contained in the kernel sources.
(+) You can support multiple languages

(-) Hard to keep printks and descriptions up-to-date. If using hashes,
    each typo fix in a printk breaks the link to your documentation.
(-) Since the developer knows the meaning of a printk best, he probably
    would be the right person to write the description.
(-) For every Distribution or vanilla kernel you probably need separate
    external message databases.

I like the fact, that every printk gets an ID in your approach and you
do not need additional printk macros.

Maybe both approaches are not mutually exclusive. If developers would
like to document their messages within the kernel sources, they still
could use kernel-doc and our KMSG_DOC macro do do that.

I admit, that I am not sure about the the best solution here.

Michael

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