On Sun, Sep 28, 2014 at 4:22 PM, Antony Pavlov <antonynpavlov@xxxxxxxxx> 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
regards,
/d
_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
