mail archive of the barebox mailing list
 help / color / mirror / Atom feed
From: Antony Pavlov <antonynpavlov@gmail.com>
To: Daniele Lacamera <daniele.lacamera@tass.be>
Cc: barebox <barebox@lists.infradead.org>,
	Michele Di Pede <michele.di.pede@tass.be>
Subject: Re: picotcp tftp support [was Adding IPv4 multicast support]
Date: Mon, 29 Sep 2014 14:19:22 +0400	[thread overview]
Message-ID: <20140929141922.b27fff3f144d14ce16b88e19@gmail.com> (raw)
In-Reply-To: <CAOngqVXJgqckdj0QsN=s2bhAjUL4hyB3GHw2XjeENkXxehY_FQ@mail.gmail.com>

On Mon, 29 Sep 2014 11:45:08 +0200
Daniele Lacamera <daniele.lacamera@tass.be> wrote:

> On Sun, Sep 28, 2014 at 4:22 PM, Antony Pavlov <antonynpavlov@gmail.com> wrote:
> >
> > 1. Do we really need this '#ifdef PICO_SUPPORT_UDP' BEFORE (!)
> > guard macro in pico_dhcp_client.h?
> >
> 
> I moved these in latest PicoTCP commit. Thanks.
> 
> 
> > 2. New pico_tftp_start_{r,t}x programming interface can be used for
> > realization legacy standalone 'tftp' command.
> > But I have no idea how to use this interface for filesystem-over-tftp
> > (it's the modern barebox' tftp realization)!
> >
> > Barebox filesystem interface needs something like this programming
> > interface:
> >
> >   struct pico_tftp_session *s;
> >
> >   s = pico_tftp_new_session_rx(addr, port, family, filename);
> >   ...
> >   filesize = pico_tftp_get_file_size(s);
> >   ...
> >   pico_tftp_receive(s, buf, len);
> >   ...
> >   pico_tftp_receive(s, buf, len);
> >   ... ... ...
> >   pico_tftp_receive(s, buf, len);
> >   ...
> >   pico_tftp_close(s);
> >
> >
> > I mean that receiving process has to be controlled by barebox,
> > not by picotcp. Because a new portion of data is received
> > by filesystem user initiative, not by network stack initiative.
> 
> Thanks for the comments. A few from my side:
> 
> - pico_tftp_receive is non-blocking, and will return immediately if no
> data is available. You always have to be bound to some RX event to be
> sure that your next receive() call is successful, so in some way you
> still want it network-bound.
> 
> - We can implement the get_file_size, but not all servers will support
> it. Michele has a strategy for developing more advanced TFTP features,
> he will post on it later

  I want just to say that barebox tries to get file size if it's possible.
  Please see tftp_parse_oack() function in fs/tftp.c:

   if (!strcmp(opt, "tsize"))
       priv->filesize = simple_strtoul(val, NULL, 10);

  This priv->filesize is used in tftp filesystem stat() call realization.
  So it's reasonable to give barebox a means to set priv->filesize
  after switching to picotcp.

-- 
Best regards,
  Antony Pavlov

_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox

  parent reply	other threads:[~2014-09-29 10:19 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-13 10:11 Adding IPv4 multicast support Colin Leitner
2014-07-13 10:55 ` Antony Pavlov
2014-07-13 10:52   ` Colin Leitner
2014-07-13 13:15     ` Colin Leitner
2014-07-13 14:28   ` Daniele Lacamera
2014-07-15  7:01     ` picotcp tftp support [was Adding IPv4 multicast support] Antony Pavlov
2014-07-15  9:31       ` Daniele Lacamera
2014-07-15 10:27         ` Antony Pavlov
2014-07-15 10:57           ` Daniele Lacamera
2014-07-15 12:57             ` Antony Pavlov
2014-07-15 15:55               ` Daniele Lacamera
2014-07-15 19:02                 ` Antony Pavlov
2014-07-16  6:30             ` Sascha Hauer
2014-07-16  6:48               ` Daniele Lacamera
2014-09-04 17:14                 ` Antony Pavlov
2014-09-05  7:37                   ` Daniele Lacamera
2014-09-26  9:27                   ` PicoTCP
2014-09-28 14:22                     ` Antony Pavlov
2014-09-29  9:45                       ` Daniele Lacamera
2014-09-29 10:10                         ` Michele Di Pede
2014-09-29 10:19                         ` Antony Pavlov [this message]
2014-07-15 18:17     ` Adding IPv4 multicast support Colin Leitner

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140929141922.b27fff3f144d14ce16b88e19@gmail.com \
    --to=antonynpavlov@gmail.com \
    --cc=barebox@lists.infradead.org \
    --cc=daniele.lacamera@tass.be \
    --cc=michele.di.pede@tass.be \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox