picotcp tftp support [was Adding IPv4 multicast support]

[Antony Pavlov]

On Tue, 15 Jul 2014 11:31:29 +0200
Daniele Lacamera <daniele.lacamera at tass.be> wrote:

> On Tue, Jul 15, 2014 at 9:01 AM, Antony Pavlov <antonynpavlov at gmail.com> wrote:
> >
> > barebox uses POSIX file interface for working with tftp.
> >
> > We have to provide these basic functions (see fs/tftp.c):
> >
> > static struct fs_driver_d tftp_driver = {
> >         .open      = tftp_open,
> >         .read      = tftp_read,
> >         .write     = tftp_write,
> >         .close     = tftp_close,
> >         /* Other functions for unlink, truncate,
> >            mkdir, rmdir, stat, opendir, lseek, create
> >            are not so important. */
> > };
> >
> > So **fs/tftp.c code is driven** by user code that
> > uses file interface for accessing to the files
> > on tftp-server.
> >
> > AFAI understand picotcp tftp support uses event-driven interface
> > so **user code is driven** by picotcp tftp support code.
> >
> > How we can use picotcp tftp support for realization
> > of POSIX file interface?
> 
> Hi Antony,
> 
> 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.

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.

> The loop will also be interruptible via CTRL+C.
> 
> I would like to know more about this approach though, are you
> implementing client only functionality (get/put) or do you want to be
> able to listen for client "connections" as well? How is the connection
> initiated (I see there is a tftp_probe function that's not included in
> the API group)?
> 
> Thanks,
> 
> /d


-- 
-- 
Best regards,
  Antony Pavlov