Remote protocol and 7-bit links

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

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?
>
>  
>

On Sat, May 27, 2006 at 11:02:18AM +1100, Steven Johnson
wrote:
> 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.

Yes, that's my plan.  The only possible lossage would be
targets which
fraudulently set the high bit on 7-bit data; I have to
disable the
stripping of that byte in order to pass binary data through.
 But I
really don't expect anything to break.

-- 
Daniel Jacobowitz
CodeSourcery

Daniel Jacobowitz wrote:

>On Sat, May 27, 2006 at 11:02:18AM +1100, Steven Johnson
wrote:
>  
>
>>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.
>>    
>>
>
>Yes, that's my plan.  The only possible lossage would
be targets which
>fraudulently set the high bit on 7-bit data; I have to
disable the
>stripping of that byte in order to pass binary data
through.  But I
>really don't expect anything to break.
>  
>
Surely that would only be the debug host doing that?  That
would be a
faulty host in my books.