[Gluster-devel] regarding gluster msg ids

[Shyamsundar Ranganathan]

Updating the thread with some more context from discussions offline
between Pranith, Krutika and myself.

The issue(s) that led to moving from a numeric ID to a string notation
of the #define was due to
   - fragmentation of the message range once allocated segments were full
   - Ability to define more developer friendly #define names, making
code better understandable
   - Based on the #define adding better meaning to the message itself

Based on this it was discussed and concluded that we will standardize
on numbers as an externally visible entity rather than have developer
defined strings as the ID,
   - so that it looks and feels consistent across components
   - as we do not need to add more meaning to the message ID but
rather to the message when required and,
   - also we need to leverage the ID as potential candidate for
journald/systemd subsystem when moving to that (potentially) in the
future.

Developers still have the flexibility to use any define names for
messages in their component, so that code reading is better.

Message range fragmentation would continue, but that is a smaller
problem which can be avoided taking larger/more segments as the
component may need/choose.

A compile time step would be added to prevent multiple definitions of
message defines (as suggested by Jeff) by adding a precompile script
to each message file to generate a conversion from #define to const
char * variants of the message.Then do a compile of this generated
header, which would fail in case there are duplicate const char *
defines. (rereading this line does seem like a lot of information in a
single line, so will follow this with a code submission to elaborate
the concept better :) ).

Shyam

On Sat, Apr 5, 2014 at 8:36 PM, Shyamsundar Ranganathan
<sam.somari at gmail.com> wrote:
> On Fri, Apr 4, 2014 at 4:07 AM, Pranith Kumar Karampuri
> <pkarampu at redhat.com> wrote:
>>
>> hi Shyam,
>>     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:
>>     - No need to worry about msg-id range segment overlaps as we are not dealing with numbers anymore.
>
> What is the current problem in segment overlaps? The intention is to
> get separate segments per component, so that way each segment is
> unique.
>
> Why wont these message names rather than numbers not clash? IOW, if 2
> components choose the same macro names then an entire name space would
> clash.
>
> Look at these message ID segments like the mem types assignments.
>
>>     - 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.
>
> Macro reuse (as stated in the followup by you) is a separate problem,
> which needs to be dealt with using gcc preprocessing of the headers
> during compile time, to eliminate the possibility of duplicate macro
> names within a single header.
>
> const char * definitions will not help catch preprocessing time format
> and types error with the __attribute__ ((__format__ (__printf__, 9,
> 10)) check.
>
>>     - 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.
>
> Admins who are looking at logs are not looking for clues from message
> ID per se, they are looking at an ID to look up and understand what it
> means, hence any unique string/number can serve as the ID. Please note
> this is not for developers to look at and debug from the logs.
>
>>
>
> Here is a broader overview of the message ID versus the string proposal from me.
> - Other similar systems use and ID, which in systemd parlance can be a
> GUID or some such distinct identifier per message (say message
> catalogs for systems from Cisco etc.)
> - A string of the form suggested is still a unique message ID, but
> when we integrate to systems like systemd, such IDs may not work, we
> need definite numbers
> - When it comes to documentation, which the admins would refer to, an
> ID is easier than a string in the message to simply put a list of
> messages up for the administrator to look at and search
>
> In short, what is the segment clash issue, and what is the code
> maintenance issue that is being discussed with the current mechanism,
> moving to a string does not seem to satisfy the requirements for this
> framework at the moment from my perspective. So it is better to
> understand what the segment allocation issue is first.
>
>> I sent a first-cut patch at: http://review.gluster.org/7398
>>
>> TODO: Remove segment related macros if you guys also like the change.
>>
>> This is one of the messages with and without patch above:
>> [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)
>> [2014-04-04 07:10:49.687053] I [MSGID: 100030] [glusterfsd.c:1914:main] 0-glusterd: Started running glusterd version 3git (args: glusterd --debug)
>>
>>
>> Pranith
>>
>> _______________________________________________
>> Gluster-devel mailing list
>> Gluster-devel at nongnu.org
>> https://lists.nongnu.org/mailman/listinfo/gluster-devel