From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14371 invoked by alias); 29 Jun 2006 09:35:15 -0000 Received: (qmail 14359 invoked by uid 22791); 29 Jun 2006 09:35:14 -0000 X-Spam-Check-By: sourceware.org Received: from main.gmane.org (HELO ciao.gmane.org) (80.91.229.2) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 29 Jun 2006 09:35:12 +0000 Received: from root by ciao.gmane.org with local (Exim 4.43) id 1FvsvO-0003br-M9 for gdb-patches@sources.redhat.com; Thu, 29 Jun 2006 11:35:02 +0200 Received: from zigzag.lvk.cs.msu.su ([158.250.17.23]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 Jun 2006 11:35:02 +0200 Received: from ghost by zigzag.lvk.cs.msu.su with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 29 Jun 2006 11:35:02 +0200 To: gdb-patches@sources.redhat.com From: Vladimir Prus Subject: Re: [rfc] Correct semantics of target_read_partial, add target_read_whole Date: Thu, 29 Jun 2006 09:35:00 -0000 Message-ID: References: <20060622032355.GA27566@nevyn.them.org> <200606221824.k5MIOsEO029253@elgar.sibelius.xs4all.nl> <20060622183739.GA17578@nevyn.them.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7Bit User-Agent: KNode/0.8.2 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/msg00400.txt.bz2 Daniel Jacobowitz wrote: > On Thu, Jun 22, 2006 at 08:24:54PM +0200, Mark Kettenis wrote: >> > Date: Wed, 21 Jun 2006 23:23:55 -0400 >> > From: Daniel Jacobowitz >> > >> > Originally, target_read_partial was supposed to read "however much it >> > could manage to" and then higher level functions were supposed to >> > handle the rest. But every existing implementation always reads enough >> > data in its first call; the one remote protocol implementation did so >> > by issuing as many packets as necessary, which defeated the point of >> > the original design. >> >> Ah, it all makes sense to me now. I'm wondering whether we should >> "export" target_read_partial() (and target_write_partial()) at all. >> It's never right to use them except for implementing higher-level >> target read/write functions isn't it? > > There's some messiness in kod.c. But didn't we decide that was on the > chopping block to be removed? Other than that, in my current working > tree there are absolutely no calls to these functions outside of > target.c. So I think you're right: we can stop exporting them at all. There are also target_write_memory_partial and target_read_memory_partial. The write variant is used only for implementation for the 'load' command. My work on implementing flash support will hopefully kill that use. The read variant is used in MI implementation of read, where, guess what, it's wrapped in a loop. I'll add replacing that loop with target_read_memory to my todo. - Volodya