From: Antony Pavlov <antonynpavlov@gmail.com>
To: Daniele Lacamera <daniele.lacamera@tass.be>
Cc: barebox <barebox@lists.infradead.org>
Subject: Re: picotcp tftp support [was Adding IPv4 multicast support]
Date: Tue, 15 Jul 2014 16:57:56 +0400 [thread overview]
Message-ID: <20140715165756.53acb0e50c0390dfefb63b6b@gmail.com> (raw)
In-Reply-To: <CAOngqVXSRuHmPL_Z73AfLPCdzitS7=kkViy2rJMvX1vvsiOhbw@mail.gmail.com>
On Tue, 15 Jul 2014 12:57:21 +0200
Daniele Lacamera <daniele.lacamera@tass.be> wrote:
> On Tue, Jul 15, 2014 at 12:27 PM, Antony Pavlov <antonynpavlov@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.
> Sorry for asking dumb questions, I am not a barebox developer and I am
> just trying to figure out what is your execution model. There
> certainly is a way to integrate my TFTP implementation as soon as I
> realize what is your model: as for instance we have blocking POSIX
> socket calls implemented with and without an OS infrastructure, and we
> are able to realize blocking calls on any systems, being baremetal or
> multithtreaded.
>
> Thanks
>
> /D
--
--
Best regards,
Antony Pavlov
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2014-07-15 12:45 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 [this message]
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
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=20140715165756.53acb0e50c0390dfefb63b6b@gmail.com \
--to=antonynpavlov@gmail.com \
--cc=barebox@lists.infradead.org \
--cc=daniele.lacamera@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