[RFC] upload/download command

[RFC] upload/download command

[Kris Warkentin]

Our QNX pdebug protocol supports an upload/download command.  This is handy
for putting binaries onto target system and getting back things like
corefiles.  Andrew had wanted me to start a discussion on the subject.

I would like to keep these things in our protocol but it might be useful to
generalize the interface out to core gdb.  What I'm thinking is that I
create a general upload/download command that uses a hook into the target's
code for any special functionality.  We could have a general one for native
targets which would basically be 'copy' (probably not all that useful but
there for completeness) and just print 'not implemented' for targets which
don't define the hooks.

Any ideas, comments, suggestions, etc.?

cheers,

Kris

Re: [RFC] upload/download command

[Daniel Jacobowitz]

On Mon, Nov 17, 2003 at 10:19:44AM -0500, Kris Warkentin wrote:
> Our QNX pdebug protocol supports an upload/download command.  This is handy
> for putting binaries onto target system and getting back things like
> corefiles.  Andrew had wanted me to start a discussion on the subject.
> 
> I would like to keep these things in our protocol but it might be useful to
> generalize the interface out to core gdb.  What I'm thinking is that I
> create a general upload/download command that uses a hook into the target's
> code for any special functionality.  We could have a general one for native
> targets which would basically be 'copy' (probably not all that useful but
> there for completeness) and just print 'not implemented' for targets which
> don't define the hooks.

Rather don't implement it for native I think... hm, might be easier to
test the core parts if we did.

> Any ideas, comments, suggestions, etc.?

For starters, how about describing how it works in your protocol? 
Obviously this could be useful to gdbserver.  For mechanics, it may
want to be another target_read_partial()...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC] upload/download command

[Kris Warkentin]

> > I would like to keep these things in our protocol but it might be useful
to
> > generalize the interface out to core gdb.  What I'm thinking is that I
> > create a general upload/download command that uses a hook into the
target's
> > code for any special functionality.  We could have a general one for
native
> > targets which would basically be 'copy' (probably not all that useful
but
> > there for completeness) and just print 'not implemented' for targets
which
> > don't define the hooks.
>
> Rather don't implement it for native I think... hm, might be easier to
> test the core parts if we did.

That's what I was thinking....it doesn't really hurt anything.

> > Any ideas, comments, suggestions, etc.?
>
> For starters, how about describing how it works in your protocol?
> Obviously this could be useful to gdbserver.  For mechanics, it may
> want to be another target_read_partial()...

We actually have a remote_fileopen command in our protocol.  The host sends
an open command to the target and then just sends blocks of data for the
target server to write out.  Then a close message tells the remote to close
it.  It's basically identical to an ordinary open command so you can open on
the remote for reading/writing/etc.

I'm not sure about gdbserver though.  Do you even presume the existence of a
filesystem on the remote?

cheers,

Kris

Re: [RFC] upload/download command

[Daniel Jacobowitz]

On Mon, Nov 17, 2003 at 10:35:12AM -0500, Kris Warkentin wrote:
> > > I would like to keep these things in our protocol but it might be useful
> to
> > > generalize the interface out to core gdb.  What I'm thinking is that I
> > > create a general upload/download command that uses a hook into the
> target's
> > > code for any special functionality.  We could have a general one for
> native
> > > targets which would basically be 'copy' (probably not all that useful
> but
> > > there for completeness) and just print 'not implemented' for targets
> which
> > > don't define the hooks.
> >
> > Rather don't implement it for native I think... hm, might be easier to
> > test the core parts if we did.
> 
> That's what I was thinking....it doesn't really hurt anything.
> 
> > > Any ideas, comments, suggestions, etc.?
> >
> > For starters, how about describing how it works in your protocol?
> > Obviously this could be useful to gdbserver.  For mechanics, it may
> > want to be another target_read_partial()...
> 
> We actually have a remote_fileopen command in our protocol.  The host sends
> an open command to the target and then just sends blocks of data for the
> target server to write out.  Then a close message tells the remote to close
> it.  It's basically identical to an ordinary open command so you can open on
> the remote for reading/writing/etc.

Sounds like a good fit for target_read_partial with the exception that
we don't have open/close right now.  I don't think we'd need to add
them for this; for that kind of copy, the remote could assume that it
would keep the file open until we'd read the whole file.  Might be more
efficient not to.

> I'm not sure about gdbserver though.  Do you even presume the existence of a
> filesystem on the remote?

Yes.  Don't confuse gdbserver with the generic remote protocol;
gdbserver is a Unix-equivalent (Linux only right now) stub, using
ptrace.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: [RFC] upload/download command

[Andrew Cagney]

> Rather don't implement it for native I think... hm, might be easier to
>> test the core parts if we did.
> 
> 
> That's what I was thinking....it doesn't really hurt anything.

A unit test that also works native is needed - without it the core code 
will bit rot within months :-/

Andrew

Re: [RFC] upload/download command

[Andrew Cagney]

> Our QNX pdebug protocol supports an upload/download command.  This is handy
> for putting binaries onto target system and getting back things like
> corefiles.  Andrew had wanted me to start a discussion on the subject.
> 
> I would like to keep these things in our protocol but it might be useful to
> generalize the interface out to core gdb.  What I'm thinking is that I
> create a general upload/download command that uses a hook into the target's
> code for any special functionality.  We could have a general one for native
> targets which would basically be 'copy' (probably not all that useful but
> there for completeness) and just print 'not implemented' for targets which
> don't define the hooks.
> 
> Any ideas, comments, suggestions, etc.?

Now that there's a generic xfer mechanism in the target vector, I think 
it is possible to implement this using something like:

	target_xfer_partial (&current_target, TARGET_OBJECT_FILE, 
<name-of-file-on-target>, <readbuf>, <writebuf>, <offset>, <length>)

(but suitably wrapped with target_read_file and target_write_file methods)

Andrew

RE: [RFC] upload/download command

[Ken Dyck]

>Our QNX pdebug protocol supports an upload/download command.  
>This is handy
>for putting binaries onto target system and getting back things like
>corefiles.

Out of curiosity, which way is up? In some circles, particularly in DSP
development, which I am most familiar with (I'm not sure if it extends
to the rest of the embedded community), the term 'download' usually
refers to pushing data down onto the target from the host machine. In
the internet world, on the other hand, the term is used to mean pulling
some data down from a remote machine onto a local host. In what sense is
the pdebug protocol using the terms?

Ken

Re: [RFC] upload/download command

[Kris Warkentin]

I would say the most common meaning for upload is to push something onto a
remote target and download means to pull something off a remote.  Ie. "I
just downloaded 10 GB of pr0n from that server." or "I just uploaded the
virus to the mainframe."

This is the sense in which we use the terms.

cheers,

Kris

----- Original Message ----- 
From: "Ken Dyck" <Ken.Dyck@dspfactory.com>
To: <kewarken@qnx.com>; <gdb@sources.redhat.com>
Sent: Monday, November 17, 2003 11:22 AM
Subject: RE: [RFC] upload/download command


>Our QNX pdebug protocol supports an upload/download command.
>This is handy
>for putting binaries onto target system and getting back things like
>corefiles.

Out of curiosity, which way is up? In some circles, particularly in DSP
development, which I am most familiar with (I'm not sure if it extends
to the rest of the embedded community), the term 'download' usually
refers to pushing data down onto the target from the host machine. In
the internet world, on the other hand, the term is used to mean pulling
some data down from a remote machine onto a local host. In what sense is
the pdebug protocol using the terms?

Ken

Re: [RFC] upload/download command

[Andrew Cagney]

> I would say the most common meaning for upload is to push something onto a
> remote target and download means to pull something off a remote.  Ie. "I
> just downloaded 10 GB of pr0n from that server." or "I just uploaded the
> virus to the mainframe."
> 
> This is the sense in which we use the terms.

Interesting, I was thinking of the exact reverse.  Looks like another 
up/down problem.  Are there other terms?  FTP's "put" and "get"?

Andrew

Re: [RFC] upload/download command

[Kris Warkentin]

> > I would say the most common meaning for upload is to push something onto
a
> > remote target and download means to pull something off a remote.  Ie. "I
> > just downloaded 10 GB of pr0n from that server." or "I just uploaded the
> > virus to the mainframe."
> >
> > This is the sense in which we use the terms.
>
> Interesting, I was thinking of the exact reverse.  Looks like another
> up/down problem.  Are there other terms?  FTP's "put" and "get"?

I think that put and get would be fine since everyone knows ftp.  I wouldn't
want to ruffle anyone's feathers by trying to change their definition of up
and down....

;-)

Kris