Re: [Gluster-devel] regarding gluster msg ids

[Shyamsundar Ranganathan]

On Fri, Apr 4, 2014 at 4:07 AM, Pranith Kumar Karampuri
<address@hidden> 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
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/gluster-devel