From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2192 invoked by alias); 27 May 2006 00:02:34 -0000 Received: (qmail 2129 invoked from network); 27 May 2006 00:02:19 -0000 Received: from unknown (202.80.33.51) by sourceware.org with QMTP; 27 May 2006 00:02:19 -0000 Received: (qmail 2153 invoked from network); 27 May 2006 00:02:18 -0000 X-Anti-Virus: Message scanned for viruses by TVL Received: from dsl2-modem31.tvl.vu (HELO [192.168.2.14]) ([202.80.43.31]) (envelope-sender ) by mail.vanuatu.com.vu (qmail-ldap-1.03) with SMTP for ; 27 May 2006 00:02:18 -0000 Message-ID: <4477970A.4070207@sakuraindustries.com> Date: Sat, 27 May 2006 01:13:00 -0000 From: Steven Johnson User-Agent: Mozilla Thunderbird 1.0.6-7.2.20060mdk (X11/20050322) MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb@sourceware.org Subject: Re: Remote protocol and 7-bit links References: <20060526221003.GA11133@nevyn.them.org> In-Reply-To: <20060526221003.GA11133@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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-05/txt/msg00377.txt.bz2 As a remote protocol user I say: Bring on 8 bit only. I haven't seen or used a UART that cant be set into 8 bits per byte since I started using them (late 80's). Its 2006, cant we deprecate the requirement for everything to be 7 bit clean, and just assume 8 bits is the way? Architectures get obsoleted faster than the requirement for everything to be 7 bit clean. Hex encoding stuff just adds work and makes life harder for the stub. As a minimum, I would say these new features be 8 bit only, and then 7 bit hobbled targets (if any actually exist) cant use them. Steven J Daniel Jacobowitz wrote: >Now that we've shaken the branches a little and found that there are at >least a couple users of the remote protocol on this list... > >Are any of you using links to targets which are not 8-bit clean? The remote >protocol, as currently defined, is strictly 7-bit with the exception of the >optional 'X' packet. I have two projects which I'll be submitting in the >near future which involve transmission of large amounts of data: > >1. Self-describing targets return hefty XML blobs. > >2. Remote file upload/download transfer, well, files. > >And I don't really want to hex encode all of this stuff if I don't have to. >A lot of remote protocol users use TCP or UDP, which obviously can handle >8-bit data. Many also use serial devices; all the ones I've used (over the >last ~ six years) have been eight bit clean, even when terminal servers were >involved. > >If this is going to be a problem, I could implement binary and non-binary >variants, or use some other mechanism to switch between. But I think that >eight bits per byte and a clean link layer which won't get too upset by >NULs are reasonable things to assume in the 21st century. And even in the >previous decade; any terminal server that can't handle eight bits can't >handle PPP... > >I'm not suggesting to change the format of any existing packet, and the new >packets I'll be adding are optional. So this wouldn't impact simplistic >stubs that don't need the new functionality (and even most descriptions for >the self-describing targets won't have 8-bit data in them). But 8-bit >support would be necessary if you wanted to support the new features. > >Any opinions, or counterexamples? > > >