Andreas Dilger wrote:
On Dec 28, 2006 19:05 -0500, Jody McIntyre wrote:
On Thu, Dec 28, 2006 at 04:43:14PM -0700, Andreas Dilger wrote:
One issue with this is if a message is unclear or otherwise lacking
information and it needs to be fixed then it presumably needs to have
a new message ID. That in turn means that the message database will
have duplicate information, or there needs to be a facility to link
different messages together like "XXXX: (previously YYYY, ZZZZ)"...
I don't understand why this duplication is a problem or why we would
need to "link" back to previous messages.
Because if there is some knowledge accumulated with message XXXX (that
is also applicable to the "same" message YYYY and ZZZZ) then it will
be a nightmare to keep all of these entries in sync if there isn't
some kind of message linking.
Consider a step-by-step debugging map that says "if you see message YYYY
proceed to step 20 to debug a network connection problem". Or if there
are translations of the message catalog, it only makes sense to do that
for "current" messages, but it is useful to know that someone running an
old version of lustre that hits YYYY or ZZZZ can look at the current web
page and find the translated message.
It also _requires_ that every analysis tool (including customers')
written to look
for particular messages _must_ change, even for trivial changes.
Maybe a smarter renumber: XXXX becomes XXXX.1 etc for changes
(with a simple unbounded increment). That way tools can be written to
look for
generic or a specific version of the message.
_______________________________________________
Lustre-devel mailing list
[email protected]
https://mail.clusterfs.com/mailman/listinfo/lustre-devel