From: Sascha Hauer <s.hauer@pengutronix.de>
To: Antony Pavlov <antonynpavlov@gmail.com>
Cc: DI PEDE Michele <michele.dipede@altran.com>,
barebox <barebox@lists.infradead.org>,
LACAMERA Daniele <daniele.lacamera@altran.com>
Subject: Re: barebox picotcp integration (2015.06.14)
Date: Wed, 17 Jun 2015 11:28:57 +0200 [thread overview]
Message-ID: <20150617092857.GJ6325@pengutronix.de> (raw)
In-Reply-To: <20150615011343.40eddc832febd97ade569cbb@gmail.com>
On Mon, Jun 15, 2015 at 01:13:43AM +0300, Antony Pavlov wrote:
> Hi!
>
> I have just published latest picotcp-enabled barebox.
> Please see my 20150614.picotcp branch in my github barebox repo
> (https://github.com/frantony/barebox/tree/20150614.picotcp).
>
> This version is based on latest barebox-next and latest picotcp-development.
> Here is barebox picotcp network features:
>
> * network interfaces and the 'ifconfig' command to rule them;
> * the 'route' command to see current picotcp route table;
> * the 'picoping' command to use picotcp ping support (also now barebox responds
> to ping requests);
> * the 'dhclient' command to use picotcp dhcp client;
> * picotcp-based tftp filesystem support.
>
> Changes since 2015.03.31:
>
> * split patches (ifconfig, route, picoping and dhclient commands
> are introduced in separate patches now);
> * rework picotcp Kconfig stuff;
> * fix formatting.
>
> Here is note/todo list:
>
> 1. tftp write operation is not supported;
Why are you using the picotcp tftp implementation? picotcp surely
supports sending/receiving udp packets, right? Wouldn't it be a good
first step to replace the barebox udp API with the one picotcp provides?
I mean I would expect that you replace only the network stack, not the
network stack including the applications. If at some point we decide
that the tftp implementation in picotcp is better than the one in
barebox that would be the time to switch it.
>
> 2. with picotcp we can't easely use 'tftp' command with old syntax
> (no $<current ethernet>.serverip anymore);
>
> 3. just now picotcp-based tftp file transfer is 5 times slower than
> old realisation (partialy it is my bad, e.g. extra memory copy operation
> is used for code simplification);
An additional memcpy shouldn't make tftp 5 times slower. There must be
something else.
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2015-06-17 9:29 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-06-14 22:13 Antony Pavlov
2015-06-17 9:28 ` Sascha Hauer [this message]
2015-06-20 11:09 ` Antony Pavlov
2015-06-22 6:00 ` Sascha Hauer
2015-06-24 6:11 ` Antony Pavlov
2015-06-26 9:54 ` Sascha Hauer
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=20150617092857.GJ6325@pengutronix.de \
--to=s.hauer@pengutronix.de \
--cc=antonynpavlov@gmail.com \
--cc=barebox@lists.infradead.org \
--cc=daniele.lacamera@altran.com \
--cc=michele.dipede@altran.com \
/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