This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Remote protocol and 7-bit links
- From: Steven Johnson <sjohnson at sakuraindustries dot com>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: gdb at sourceware dot org
- Date: Sat, 27 May 2006 11:02:18 +1100
- Subject: Re: Remote protocol and 7-bit links
- References: <20060526221003.GA11133@nevyn.them.org>
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?
>
>
>