From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8179 invoked by alias); 22 Jun 2006 12:39:48 -0000 Received: (qmail 8171 invoked by uid 22791); 22 Jun 2006 12:39:47 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Thu, 22 Jun 2006 12:39:45 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FtOTG-0001o9-QR; Thu, 22 Jun 2006 08:39:42 -0400 Date: Thu, 22 Jun 2006 13:17:00 -0000 From: Daniel Jacobowitz To: Vladimir Prus Cc: gdb@sources.redhat.com Subject: Re: [remote] RFC: Replace qPart with qXfer Message-ID: <20060622123942.GB6782@nevyn.them.org> Mail-Followup-To: Vladimir Prus , gdb@sources.redhat.com References: <20060622031731.GA26722@nevyn.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.11+cvs20060403 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2006-06/txt/msg00184.txt.bz2 On Thu, Jun 22, 2006 at 12:41:45PM +0400, Vladimir Prus wrote: > Daniel Jacobowitz wrote: > > > `qXfer:OBJECT:read:ANNEX:OFFSET,LENGTH' > > Read uninterpreted bytes from the target's special data area > > identified by the keyword OBJECT. Request LENGTH bytes starting > > at OFFSET bytes into the data. The content and encoding of ANNEX > > is specific to the object; it can supply additional details about > > what data to access. > > Why do we need OBJECT+ANNEX addressing and opposed to just OBJECT? If > 'OBJECT' is just a string, can't we push anything in it, without needed > extra level of addressing? I inherited this from qPart, but I think it's a good idea - I actually use it for XML descriptions. OBJECT is the base of the request. All "qXfer:OBJECT:read" requests for a single value of OBJECT are expected to be handled in the same way. A stub which supports this OBJECT should return a non-empty response. ANNEX is a bit of auxilliary data, in case there's more than one instance of OBJECT. For instance: qXfer:features:read:target.xml:0,100 Read the overall target description. qXfer:features:read:CHECKSUMS:0,100 Read any precomputed SHA-1 checksums for target description files. qXfer:features:read:foo.xml:0,100 Read a specific XML file referenced using XInclude. And then, if one of those is unavailable, it can return either "l" (no data), or "E00" (annex unknown, or something else wrong with the packet). Sure, you could call that "qXfer:features-target.xml:read". But it's trickier for the target stub to match it in that case. -- Daniel Jacobowitz CodeSourcery