picotcp tftp support [was Adding IPv4 multicast support]

[Daniele Lacamera]

On Tue, Jul 15, 2014 at 2:57 PM, Antony Pavlov <antonynpavlov at gmail.com> wrote:
> On Tue, 15 Jul 2014 12:57:21 +0200
> Daniele Lacamera <daniele.lacamera at tass.be> wrote:
>
>> On Tue, Jul 15, 2014 at 12:27 PM, Antony Pavlov <antonynpavlov at gmail.com> wrote:
>>
>> >> I will be able to provide such an interface by using a similar
>> >> approach to what you used for ping (so via net_poll() routine called
>> >> in a loop), assuming that your posix-like interface expects blocking
>> >> calls for read/write operations.
>> >
>> > Alas! We can't use this approach for tftp because tftp is a FILESYSTEM in barebox.
>>
>> Then again, I'd like to know if your FS implementation actually needs
>> blocking call, and in case, where is the code supposed to block. Does
>> barebox have some kind of support for multiple threads, or a default
>> event loop where background operations can be added? Or are the FS
>> calls non blocking?
>
> AFAIK barebox does not support threads.
> Also all filesystem calls are blocking.
>

Then for me it is still not clear *where* a filesystem call is
blocking. On a multi-threaded system, the calls is supposed to block
somewhere in thread_sleep() functions. On a single thread execution
model, we will need to tick the TCP/IP stack in the background while
the call is "busy". Suppose that you issue a read call to any network
filesystem (in this case TFTP issuing a get command). The file needs
to be retreived by the TCP/IP stack, so I guess that the only
implementation that makes sense would be something like:

while (callback_has_not_been_called) {
   if(ctrlc())
     break;
   pico_stack_tick();
   // maybe sleep here
}

What you stated earlier, i.e.
> Tftp user code know nothing about network stuff. User code just use read and write
> for acessing file data, no matter which driver (ramdisk, SATA, MTD, I2C or network)
> is used for actual data transfer.

does not make much sense to me, as the network is required to access
remote files, so the stack needs to tick constantly under the hood if
you want to receive packets while your read call is blocked waiting
for data.

User does not need to know that her read call is going through the
network, but the TFTP fs module (or another underlying "driver") is
supposed to access the picotcp API properly to retrieve the data
needed when I/O operations are running. The intermediate layer (the
new fs/tftp.c) is supposed to issue a stack tick whenever it is
suspended waiting for network events.

Finally, I will assume that the use case needed is TFTP working in
client mode, issuing GET/PUT commands upon open posix calls.

I can provide to you (and the list) an example implementation, which I
will develop on top of your latest picotcp branch and test via
sandbox/tuntap. In the meanwhile, any comment on the topic by barebox
developers are more than welcome.

Thanks

/d