<html><body><div style="font-family: lucida console,sans-serif; font-size: 12pt; color: #000000"><div><br></div><div>This is really interesting - I've worked on systems (z series) that used msgid's across a mass of products, based on a <product prefix><seq#><severity> format<br></div><div><br></div><div>That worked really well, since operations picked up on the prefix and immediately new what subsystem the message related to....and whether to panic or not :) The messages could also be sent to the same logging subsystem, and then automation could just pick the one file and get a view across all products.<br></div><div><br></div><div>Ahhh - good times :)<br></div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div><hr id="zwchr"><blockquote style="border-left:2px solid #1010FF;margin-left:5px;padding-left:5px;color:#000;font-weight:normal;font-style:normal;text-decoration:none;font-family:Helvetica,Arial,sans-serif;font-size:12pt;"><b>From: </b>"Shyamsundar Ranganathan" <sam.somari@gmail.com><br><b>To: </b>"Pranith Kumar Karampuri" <pkarampu@redhat.com><br><b>Cc: </b>"Ravishankar Narayanankutty" <ranaraya@redhat.com>, "Gluster Devel" <gluster-devel@nongnu.org>, "Shyamsundar Ranganathan" <shyamsundarr@gmail.com><br><b>Sent: </b>Friday, 11 April, 2014 1:10:26 PM<br><b>Subject: </b>Re: [Gluster-devel] regarding gluster msg ids<br><div><br></div>Updating the thread with some more context from discussions offline<br>between Pranith, Krutika and myself.<br><div><br></div>The issue(s) that led to moving from a numeric ID to a string notation<br>of the #define was due to<br> - fragmentation of the message range once allocated segments were full<br> - Ability to define more developer friendly #define names, making<br>code better understandable<br> - Based on the #define adding better meaning to the message itself<br><div><br></div>Based on this it was discussed and concluded that we will standardize<br>on numbers as an externally visible entity rather than have developer<br>defined strings as the ID,<br> - so that it looks and feels consistent across components<br> - as we do not need to add more meaning to the message ID but<br>rather to the message when required and,<br> - also we need to leverage the ID as potential candidate for<br>journald/systemd subsystem when moving to that (potentially) in the<br>future.<br><div><br></div>Developers still have the flexibility to use any define names for<br>messages in their component, so that code reading is better.<br><div><br></div>Message range fragmentation would continue, but that is a smaller<br>problem which can be avoided taking larger/more segments as the<br>component may need/choose.<br><div><br></div>A compile time step would be added to prevent multiple definitions of<br>message defines (as suggested by Jeff) by adding a precompile script<br>to each message file to generate a conversion from #define to const<br>char * variants of the message.Then do a compile of this generated<br>header, which would fail in case there are duplicate const char *<br>defines. (rereading this line does seem like a lot of information in a<br>single line, so will follow this with a code submission to elaborate<br>the concept better :) ).<br><div><br></div>Shyam<br><div><br></div>On Sat, Apr 5, 2014 at 8:36 PM, Shyamsundar Ranganathan<br><sam.somari@gmail.com> wrote:<br>> On Fri, Apr 4, 2014 at 4:07 AM, Pranith Kumar Karampuri<br>> <pkarampu@redhat.com> wrote:<br>>><br>>> hi Shyam,<br>>> Instead of printing numbers as msg-ids, could we print the stringification of macro itself as the msg-id? Reasons why I feel this is better:<br>>> - No need to worry about msg-id range segment overlaps as we are not dealing with numbers anymore.<br>><br>> What is the current problem in segment overlaps? The intention is to<br>> get separate segments per component, so that way each segment is<br>> unique.<br>><br>> Why wont these message names rather than numbers not clash? IOW, if 2<br>> components choose the same macro names then an entire name space would<br>> clash.<br>><br>> Look at these message ID segments like the mem types assignments.<br>><br>>> - macro re-use in same file will cause compilation error. Different msg-id.h files will have different prefixes for msg-ids so there should not be any collisions across components.<br>><br>> Macro reuse (as stated in the followup by you) is a separate problem,<br>> which needs to be dealt with using gcc preprocessing of the headers<br>> during compile time, to eliminate the possibility of duplicate macro<br>> names within a single header.<br>><br>> const char * definitions will not help catch preprocessing time format<br>> and types error with the __attribute__ ((__format__ (__printf__, 9,<br>> 10)) check.<br>><br>>> - We can choose to give easy-to-remember msg-ids like AFR-SPLIT-BRAIN if we want to. No need to lookup what msg-id means etc.<br>><br>> Admins who are looking at logs are not looking for clues from message<br>> ID per se, they are looking at an ID to look up and understand what it<br>> means, hence any unique string/number can serve as the ID. Please note<br>> this is not for developers to look at and debug from the logs.<br>><br>>><br>><br>> Here is a broader overview of the message ID versus the string proposal from me.<br>> - Other similar systems use and ID, which in systemd parlance can be a<br>> GUID or some such distinct identifier per message (say message<br>> catalogs for systems from Cisco etc.)<br>> - A string of the form suggested is still a unique message ID, but<br>> when we integrate to systems like systemd, such IDs may not work, we<br>> need definite numbers<br>> - When it comes to documentation, which the admins would refer to, an<br>> ID is easier than a string in the message to simply put a list of<br>> messages up for the administrator to look at and search<br>><br>> In short, what is the segment clash issue, and what is the code<br>> maintenance issue that is being discussed with the current mechanism,<br>> moving to a string does not seem to satisfy the requirements for this<br>> framework at the moment from my perspective. So it is better to<br>> understand what the segment allocation issue is first.<br>><br>>> I sent a first-cut patch at: http://review.gluster.org/7398<br>>><br>>> TODO: Remove segment related macros if you guys also like the change.<br>>><br>>> This is one of the messages with and without patch above:<br>>> [2014-04-04 07:08:53.113969] I [MSGID: glusterfsd_msg_30] [glusterfsd.c:1914:main] 0-glusterd: Started running glusterd version 3git (args: glusterd --debug)<br>>> [2014-04-04 07:10:49.687053] I [MSGID: 100030] [glusterfsd.c:1914:main] 0-glusterd: Started running glusterd version 3git (args: glusterd --debug)<br>>><br>>><br>>> Pranith<br>>><br>>> _______________________________________________<br>>> Gluster-devel mailing list<br>>> Gluster-devel@nongnu.org<br>>> https://lists.nongnu.org/mailman/listinfo/gluster-devel<br><div><br></div>_______________________________________________<br>Gluster-devel mailing list<br>Gluster-devel@nongnu.org<br>https://lists.nongnu.org/mailman/listinfo/gluster-devel<br></blockquote><div><br></div></div></body></html>