From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32096 invoked by alias); 22 Jun 2006 18:18:02 -0000 Received: (qmail 32087 invoked by uid 22791); 22 Jun 2006 18:18:02 -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 18:18:00 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FtTkc-0004Qu-3S; Thu, 22 Jun 2006 14:17:58 -0400 Date: Thu, 22 Jun 2006 18:18:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb-patches@sourceware.org Subject: Re: [rfc] Allow xfer_partial to signal EOF out of band Message-ID: <20060622181758.GA16981@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb-patches@sourceware.org References: <20060622033609.GA28010@nevyn.them.org> <200606221812.k5MICoV7025706@elgar.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200606221812.k5MICoV7025706@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.11+cvs20060403 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-06/txt/msg00327.txt.bz2 On Thu, Jun 22, 2006 at 08:12:50PM +0200, Mark Kettenis wrote: > > Date: Wed, 21 Jun 2006 23:36:09 -0400 > > From: Daniel Jacobowitz > > > > This patch adds a mechanism for to_xfer_partial to signal that it's done. > > I didn't implement the new mechanism for any other targets besides remote; > > it could easily be done for e.g. procfs_read_auxv, but the turnaround time > > is such that it's not a big deal either way. For the remote protocol, > > where there's an extra round trip to the remote link, I set *no_more if > > the target tells me to. > > I don't like this at all. I think target_read_partial already has > enough arguments. And having read-like function calls return zero on > EOF is a well-established practice. OK. > > Any comments on this? Otherwise, I'll commit it after qXfer:auxv:read. > > This is the patch which actually saves one packet whenever a remote object > > is transferred. > > Does that really impact performance? If it does, I think you should > add some state to the remote protocol and use that to prevent it from > sending a packet. I haven't measured it; it just tickles my sense of the ridiculous to waste the round trip. I bet you're right and I can do this within the remote protocol specific code fairly easily - I'll give that a try. -- Daniel Jacobowitz CodeSourcery