From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3970 invoked by alias); 12 May 2006 20:07:46 -0000 Received: (qmail 3789 invoked by uid 22791); 12 May 2006 20:07:44 -0000 X-Spam-Check-By: sourceware.org Received: from e35.co.us.ibm.com (HELO e35.co.us.ibm.com) (32.97.110.153) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 12 May 2006 20:07:42 +0000 Received: from d03relay04.boulder.ibm.com (d03relay04.boulder.ibm.com [9.17.195.106]) by e35.co.us.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id k4CK7eM3015059 for ; Fri, 12 May 2006 16:07:40 -0400 Received: from d03av02.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.195.168]) by d03relay04.boulder.ibm.com (8.12.10/NCO/VER6.8) with ESMTP id k4CK7eM9172014 for ; Fri, 12 May 2006 14:07:40 -0600 Received: from d03av02.boulder.ibm.com (loopback [127.0.0.1]) by d03av02.boulder.ibm.com (8.12.11/8.13.3) with ESMTP id k4CK7dC3008117 for ; Fri, 12 May 2006 14:07:39 -0600 Received: from dufur.beaverton.ibm.com (dufur.beaverton.ibm.com [9.47.22.20]) by d03av02.boulder.ibm.com (8.12.11/8.12.11) with ESMTP id k4CK7dEY008102; Fri, 12 May 2006 14:07:39 -0600 Subject: Re: CLI and GDB/MI documentation patch From: PAUL GILLIAM Reply-To: pgilliam@us.ibm.com To: Eli Zaretskii Cc: gdb-patches@sourceware.org In-Reply-To: References: <20060512011730.GA26655@brasko.net> <20060512124940.GB3860@nevyn.them.org> <20060512135802.GA6472@nevyn.them.org> <20060512183723.GA14434@nevyn.them.org> Content-Type: text/plain Date: Fri, 12 May 2006 20:26:00 -0000 Message-Id: <1147460632.3672.81.camel@dufur.beaverton.ibm.com> Mime-Version: 1.0 X-Mailer: Evolution 2.2.2 (2.2.2-5) Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00261.txt.bz2 On Fri, 2006-05-12 at 21:55 +0300, Eli Zaretskii wrote: > If you feel we should tell how to create a front end and/or a stub > that supports several versions of GDB/MI or remote protocol, that's > fine by me, but let's have sections whose focus is to provide tips to > such programmers, not to tell the history of MI or the protocol's > evolution. That's quite a different attitude than what Bob wrote. Why not have a section in the internals manual: something like "How to (and not to) write frontends for GDB"? -=# Paul #=-