From: Antony Pavlov <antonynpavlov@gmail.com>
To: Sascha Hauer <s.hauer@pengutronix.de>
Cc: barebox@lists.infradead.org
Subject: Re: [RFC 04/12] WIP: fs/nfs.c: convert to picotcp
Date: Fri, 17 Jul 2015 10:18:26 +0300 [thread overview]
Message-ID: <20150717101826.8b7440dfe537ba4fd8318a9f@gmail.com> (raw)
In-Reply-To: <20150716195150.GG18700@pengutronix.de>
On Thu, 16 Jul 2015 21:51:50 +0200
Sascha Hauer <s.hauer@pengutronix.de> wrote:
> Hi Antony,
>
> On Wed, Jul 15, 2015 at 11:13:42PM +0300, Antony Pavlov wrote:
> > Signed-off-by: Antony Pavlov <antonynpavlov@gmail.com>
> > ---
> > fs/nfs.c | 150 +++++++++++++++++++++++++++++++++++++++++++++++++++++++--------
> > 1 file changed, 133 insertions(+), 17 deletions(-)
> >
> > @@ -1346,19 +1424,38 @@ static int nfs_probe(struct device_d *dev)
> >
> > npriv->path = xstrdup(path + 1);
> >
> > - npriv->server = resolv(tmp);
> > + if (IS_ENABLED(CONFIG_NET_LEGACY)) {
> > + npriv->server = resolv(tmp);
> > + } else if (IS_ENABLED(CONFIG_NET_PICOTCP)) {
> > + /* FIXME: check corectness */
> > + npriv->remote_address.ip4.addr = resolv(tmp);
> > + }
> >
> > debug("nfs: server: %s path: %s\n", tmp, npriv->path);
> >
> > - npriv->con = net_udp_new(npriv->server, 0, nfs_handler, npriv);
> > - if (IS_ERR(npriv->con)) {
> > - ret = PTR_ERR(npriv->con);
> > - goto err1;
> > + if (IS_ENABLED(CONFIG_NET_LEGACY)) {
> > + npriv->con = net_udp_new(npriv->server, 0, nfs_handler, npriv);
> > + if (IS_ERR(npriv->con)) {
> > + ret = PTR_ERR(npriv->con);
> > + goto err1;
> > + }
> > +
> > + /* Need a priviliged source port */
> > + net_udp_bind(npriv->con, 1000);
> > + } else if (IS_ENABLED(CONFIG_NET_PICOTCP)) {
> > + /* FIXME: 2048 */
> > + npriv->pkt = xzalloc(2048);
> > +
> > + /* Need a priviliged source port */
> > + npriv->sock = nfs_socket_open(1000);
> > + if (!npriv->sock) {
> > + ret = -1;
> > + goto err1;
> > + }
> > +
> > + npriv->sock->priv = npriv;
> > }
>
> The different network stacks should be transparent to the users. Instead
> of implementing them in tftp/nfs/... I would expect the abstraction in the
> current network functions, something like:
It's near impossible with current network stack implementation.
We have to drop direct access to net_connection private fields from application code;
e.g. direct access to packet UDP fields in tftp code:
priv->tftp_con->udp->uh_dport = uh_sport;
My patch series was not intended to change legacy network code in any way.
On the contrary it intentionaly keeps original code "as is".
This approach demonstrates in practice picotcp and legacy network stack differences,
so future work on integration is much more evident.
I can start next round of picotcp integration with removing direct access to net_connection private fields
from application code.
> struct net_connection *net_udp_new(IPaddr_t dest, uint16_t dport,
> rx_handler_f *handler, void *ctx)
> {
> struct net_connection *con = net_new(dest, handler, ctx);
> if (IS_ERR(con))
> return con;
>
> con->proto = IPPROTO_UDP;
> con->udp->uh_dport = htons(dport);
> con->udp->uh_sport = htons(net_udp_new_localport());
> con->ip->protocol = IPPROTO_UDP;
>
> if (IS_ENABLED(CONFIG_NET_PICOTCP)) {
> con->sock = pico_socket_open(PICO_PROTO_IPV4, PICO_PROTO_UDP, handler);
> }
>
> return con;
> }
>
> static inline int net_udp_bind(struct net_connection *con, int sport)
> {
> if (IS_ENABLED(CONFIG_NET_PICOTCP)) {
> memset(&local_address, 0, sizeof(union pico_address));
> pico_socket_bind(con->sock, &local_address, &sport);
> } else {
> con->udp->uh_sport = ntohs(sport);
> }
>
> return 0;
> }
>
> int net_udp_send(struct net_connection *con, int len)
> {
> if (IS_ENABLED(CONFIG_NET_PICOTCP)) {
> return pico_socket_sendto(con->sock, npriv->pkt,
> sizeof(pkt) + datalen * sizeof(uint32_t),
> con->ip->daddr, con->udp->uh_dport);
> }
>
> con->udp->uh_ulen = htons(len + 8);
> con->udp->uh_sum = 0;
>
> return net_ip_send(con, sizeof(struct udphdr) + len);
> }
>
> The APIs between current barebox implementation and picotcp probably do
> not match exactly. Where the APIs don't match we can change the existing
> barebox API to what picotcp expects.
Yeah, picotcp uses more advanced API so we have to "pull up" existing API.
>
> With that the remaining pieces like DHCP, netconsole and DNS would work
> without additional effort.
--
Best regards,
Antony Pavlov
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
next prev parent reply other threads:[~2015-07-17 7:11 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-07-15 20:13 [RFC 00/12] barebox picotcp integration (2015.07.15) Antony Pavlov
2015-07-15 20:13 ` [RFC 01/12] picotcp: add barebox target support Antony Pavlov
2015-07-15 20:13 ` [RFC 02/12] picotcp: switch to Kbuild Antony Pavlov
2015-07-15 20:13 ` [RFC 03/12] net: add initial picotcp support Antony Pavlov
2015-07-15 20:13 ` [RFC 04/12] WIP: fs/nfs.c: convert to picotcp Antony Pavlov
2015-07-16 19:51 ` Sascha Hauer
2015-07-17 7:18 ` Antony Pavlov [this message]
2015-07-15 20:13 ` [RFC 05/12] WIP: fs/tftp.c: " Antony Pavlov
2015-07-15 20:13 ` [RFC 06/12] WIP: net/dns: " Antony Pavlov
2015-07-15 20:13 ` [RFC 07/12] net: picotcp: add test_picotcp command Antony Pavlov
2015-07-15 20:13 ` [RFC 08/12] net: picotcp: add ifconfig command Antony Pavlov
2015-07-15 20:13 ` [RFC 09/12] net: picotcp: add ping command Antony Pavlov
2015-07-15 20:13 ` [RFC 10/12] net: picotcp: add route command Antony Pavlov
2015-07-15 20:13 ` [RFC 11/12] sandbox_defconfig: switch to picotcp Antony Pavlov
2015-07-15 20:13 ` [RFC 12/12] WIP: sandbox_defconfig: enable network testing-related stuff Antony Pavlov
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=20150717101826.8b7440dfe537ba4fd8318a9f@gmail.com \
--to=antonynpavlov@gmail.com \
--cc=barebox@lists.infradead.org \
--cc=s.hauer@pengutronix.de \
/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