From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30779 invoked by alias); 26 May 2006 22:12:19 -0000 Received: (qmail 30771 invoked by uid 22791); 26 May 2006 22:12:18 -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; Fri, 26 May 2006 22:10:06 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1FjkVP-0002vm-UU for gdb@sourceware.org; Fri, 26 May 2006 18:10:04 -0400 Date: Sat, 27 May 2006 00:44:00 -0000 From: Daniel Jacobowitz To: gdb@sourceware.org Subject: Remote protocol and 7-bit links Message-ID: <20060526221003.GA11133@nevyn.them.org> Mail-Followup-To: gdb@sourceware.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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-05/txt/msg00376.txt.bz2 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? -- Daniel Jacobowitz CodeSourcery