From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-61756-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 6154 invoked by alias); 18 Feb 2009 04:11:51 -0000
Received: (qmail 5907 invoked by uid 22791); 18 Feb 2009 04:11:49 -0000
X-SWARE-Spam-Status: No, hits=-1.0 required=5.0 	tests=AWL,BAYES_05,SPF_SOFTFAIL
X-Spam-Check-By: sourceware.org
Received: from mtaout7.012.net.il (HELO mtaout7.012.net.il) (84.95.2.19)     by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 18 Feb 2009 04:11:42 +0000
Received: from conversion-daemon.i-mtaout7.012.net.il by i-mtaout7.012.net.il (HyperSendmail v2007.08) id <0KF800000TZXEX00@i-mtaout7.012.net.il> for gdb-patches@sources.redhat.com; Wed, 18 Feb 2009 06:10:41 +0200 (IST)
Received: from HOME-C4E4A596F7 ([84.228.82.14]) by i-mtaout7.012.net.il (HyperSendmail v2007.08) with ESMTPA id <0KF800LWFU9SKLC0@i-mtaout7.012.net.il>; Wed, 18 Feb 2009 06:10:41 +0200 (IST)
Date: Wed, 18 Feb 2009 04:24:00 -0000
From: Eli Zaretskii <eliz@gnu.org>
Subject: Re: MI solib notification
In-reply-to: <gnfamp$skf$1@ger.gmane.org>
To: Vladimir Prus <vladimir@codesourcery.com>
Cc: gdb-patches@sources.redhat.com
Reply-to: Eli Zaretskii <eliz@gnu.org>
Message-id: <ur61wv0zm.fsf@gnu.org>
References: <200901310010.46738.vladimir@codesourcery.com> <200902172208.37427.vladimir@codesourcery.com> <u4oysx3qq.fsf@gnu.org> <200902172244.48437.vladimir@codesourcery.com> <uy6w4vmdt.fsf@gnu.org> <gnfamp$skf$1@ger.gmane.org>
X-IsSubscribed: yes
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb-patches.sourceware.org>
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2009-02/txt/msg00375.txt.bz2

> From:  Vladimir Prus <vladimir@codesourcery.com>
> Date:  Wed, 18 Feb 2009 00:37:29 +0300
> 
> >     @item =library-loaded,@var{info}
> >     Reports that a new library file was loaded by the program.  @var{info}
> >     includes 4 fields:
> > 
> >     @table @code
> >     @item id="@var{id}"
> >     Opaque identifier of the library.
> >     @item target-name="@var{target-name}"
> >     @itemx host-name="@var{host-name}"
> >     For remote debugging case, @var{target-name} and @var{host-name}
> >     fields give the name of the library file on the target, and on the
> >     host respectively.  For native debugging, both those fields have the
> >     same value.
> >     ...
> > 
> > etc., you get the idea.  What you suggested now is very close to this,
> > but I think my suggestion makes it easier to read and grasp.
> 
> I think the way you suggest is more complex. It introduces a new symbol 'info' 
> that does not actually correspond to standalone entity in MI output and users
> might begin to wonder what info actually is, and how it includes fields. Saying
> that notification itself has 4 fields is more direct.

OK, but then how about using a @table to describe those 4 fields?