[U-Boot] [PATCH 1/4] nfs: convert supported_nfs_versions bitfield to an enum

[U-Boot] [PATCH 1/4] nfs: convert supported_nfs_versions bitfield to an enum

[Christian Gmeiner]

From: Thomas RIENOESSL <thomas.rienoessl@bachmann.info>

Prep. work to support nfs v1.

Signed-off-by: Thomas RIENOESSL <thomas.rienoessl@bachmann.info>
---
 net/nfs.c | 79 +++++++++++++++++++++++++++++++------------------------
 1 file changed, 45 insertions(+), 34 deletions(-)

diff --git a/net/nfs.c b/net/nfs.c
index d6a7f8e827..81c08de626 100644
--- a/net/nfs.c
+++ b/net/nfs.c
@@ -74,10 +74,13 @@ static char *nfs_filename;
 static char *nfs_path;
 static char nfs_path_buff[2048];
 
-#define NFSV2_FLAG 1
-#define NFSV3_FLAG 1 << 1
-static char supported_nfs_versions = NFSV2_FLAG | NFSV3_FLAG;
+enum nfs_version {
+	NFS_UNKOWN = 0,
+	NFS_V2 = 2,
+	NFS_V3 = 3,
+};
 
+static enum nfs_version choosen_nfs_version = NFS_V3;
 static inline int store_block(uchar *src, unsigned offset, unsigned len)
 {
 	ulong newsize = offset + len;
@@ -185,10 +188,19 @@ static void rpc_req(int rpc_prog, int rpc_proc, uint32_t *data, int datalen)
 	rpc_pkt.u.call.prog = htonl(rpc_prog);
 	switch (rpc_prog) {
 	case PROG_NFS:
-		if (supported_nfs_versions & NFSV2_FLAG)
-			rpc_pkt.u.call.vers = htonl(2);	/* NFS v2 */
-		else /* NFSV3_FLAG */
-			rpc_pkt.u.call.vers = htonl(3);	/* NFS v3 */
+		switch (choosen_nfs_version) {
+		case NFS_V2:
+			rpc_pkt.u.call.vers = htonl(2);
+			break;
+
+		case NFS_V3:
+			rpc_pkt.u.call.vers = htonl(3);
+			break;
+
+		case NFS_UNKOWN:
+			/* nothing to do */
+			break;
+		}
 		break;
 	case PROG_PORTMAP:
 	case PROG_MOUNT:
@@ -296,7 +308,7 @@ static void nfs_readlink_req(void)
 	p = &(data[0]);
 	p = rpc_add_credentials(p);
 
-	if (supported_nfs_versions & NFSV2_FLAG) {
+	if (choosen_nfs_version == NFS_V2) {
 		memcpy(p, filefh, NFS_FHSIZE);
 		p += (NFS_FHSIZE / 4);
 	} else { /* NFSV3_FLAG */
@@ -325,7 +337,7 @@ static void nfs_lookup_req(char *fname)
 	p = &(data[0]);
 	p = rpc_add_credentials(p);
 
-	if (supported_nfs_versions & NFSV2_FLAG) {
+	if (choosen_nfs_version == NFS_V2) {
 		memcpy(p, dirfh, NFS_FHSIZE);
 		p += (NFS_FHSIZE / 4);
 		*p++ = htonl(fnamelen);
@@ -365,7 +377,7 @@ static void nfs_read_req(int offset, int readlen)
 	p = &(data[0]);
 	p = rpc_add_credentials(p);
 
-	if (supported_nfs_versions & NFSV2_FLAG) {
+	if (choosen_nfs_version == NFS_V2) {
 		memcpy(p, filefh, NFS_FHSIZE);
 		p += (NFS_FHSIZE / 4);
 		*p++ = htonl(offset);
@@ -395,13 +407,13 @@ static void nfs_send(void)
 
 	switch (nfs_state) {
 	case STATE_PRCLOOKUP_PROG_MOUNT_REQ:
-		if (supported_nfs_versions & NFSV2_FLAG)
+		if (choosen_nfs_version == NFS_V2)
 			rpc_lookup_req(PROG_MOUNT, 1);
 		else  /* NFSV3_FLAG */
 			rpc_lookup_req(PROG_MOUNT, 3);
 		break;
 	case STATE_PRCLOOKUP_PROG_NFS_REQ:
-		if (supported_nfs_versions & NFSV2_FLAG)
+		if (choosen_nfs_version == NFS_V2)
 			rpc_lookup_req(PROG_NFS, 2);
 		else  /* NFSV3_FLAG */
 			rpc_lookup_req(PROG_NFS, 3);
@@ -528,31 +540,30 @@ static int nfs_lookup_reply(uchar *pkt, unsigned len)
 		switch (ntohl(rpc_pkt.u.reply.astatus)) {
 		case NFS_RPC_SUCCESS: /* Not an error */
 			break;
-		case NFS_RPC_PROG_MISMATCH:
+		case NFS_RPC_PROG_MISMATCH: {
 			/* Remote can't support NFS version */
-			switch (ntohl(rpc_pkt.u.reply.data[0])) {
-			/* Minimal supported NFS version */
-			case 3:
-				debug("*** Warning: NFS version not supported: Requested: V%d, accepted: min V%d - max V%d\n",
-				      (supported_nfs_versions & NFSV2_FLAG) ?
-						2 : 3,
-				      ntohl(rpc_pkt.u.reply.data[0]),
-				      ntohl(rpc_pkt.u.reply.data[1]));
-				debug("Will retry with NFSv3\n");
-				/* Clear NFSV2_FLAG from supported versions */
-				supported_nfs_versions &= ~NFSV2_FLAG;
-				return -NFS_RPC_PROG_MISMATCH;
-			case 4:
-			default:
+			const int min = ntohl(rpc_pkt.u.reply.data[0]);
+			const int max = ntohl(rpc_pkt.u.reply.data[1]);
+
+			if (max < NFS_V2 || max > NFS_V3 || min > NFS_V3) {
 				puts("*** ERROR: NFS version not supported");
 				debug(": Requested: V%d, accepted: min V%d - max V%d\n",
-				      (supported_nfs_versions & NFSV2_FLAG) ?
-						2 : 3,
+				      choosen_nfs_version,
 				      ntohl(rpc_pkt.u.reply.data[0]),
 				      ntohl(rpc_pkt.u.reply.data[1]));
 				puts("\n");
+				choosen_nfs_version = NFS_UNKOWN;
+				break;
 			}
-			break;
+
+			debug("*** Warning: NFS version not supported: Requested: V%d, accepted: min V%d - max V%d\n",
+					choosen_nfs_version,
+					ntohl(rpc_pkt.u.reply.data[0]),
+					ntohl(rpc_pkt.u.reply.data[1]));
+			debug("Will retry with NFSv%d\n", min);
+			choosen_nfs_version = min;
+			return -NFS_RPC_PROG_MISMATCH;
+		}
 		case NFS_RPC_PROG_UNAVAIL:
 		case NFS_RPC_PROC_UNAVAIL:
 		case NFS_RPC_GARBAGE_ARGS:
@@ -565,7 +576,7 @@ static int nfs_lookup_reply(uchar *pkt, unsigned len)
 		return -1;
 	}
 
-	if (supported_nfs_versions & NFSV2_FLAG) {
+	if (choosen_nfs_version == NFS_V2) {
 		memcpy(filefh, rpc_pkt.u.reply.data + 1, NFS_FHSIZE);
 	} else {  /* NFSV3_FLAG */
 		filefh3_length = ntohl(rpc_pkt.u.reply.data[1]);
@@ -626,7 +637,7 @@ static int nfs_readlink_reply(uchar *pkt, unsigned len)
 	    rpc_pkt.u.reply.data[0])
 		return -1;
 
-	if (!(supported_nfs_versions & NFSV2_FLAG)) { /* NFSV3_FLAG */
+	if (choosen_nfs_version == NFS_V3) {
 		nfsv3_data_offset =
 			nfs3_get_attributes_offset(rpc_pkt.u.reply.data);
 	}
@@ -684,7 +695,7 @@ static int nfs_read_reply(uchar *pkt, unsigned len)
 	if (!(nfs_offset % ((NFS_READ_SIZE / 2) * 10)))
 		putc('#');
 
-	if (supported_nfs_versions & NFSV2_FLAG) {
+	if (choosen_nfs_version == NFS_V2) {
 		rlen = ntohl(rpc_pkt.u.reply.data[18]);
 		data_ptr = (uchar *)&(rpc_pkt.u.reply.data[19]);
 	} else {  /* NFSV3_FLAG */
@@ -787,7 +798,7 @@ static void nfs_handler(uchar *pkt, unsigned dest, struct in_addr sip,
 			nfs_state = STATE_UMOUNT_REQ;
 			nfs_send();
 		} else if (reply == -NFS_RPC_PROG_MISMATCH &&
-			   supported_nfs_versions != 0) {
+			   choosen_nfs_version != NFS_UNKOWN) {
 			/* umount */
 			nfs_state = STATE_UMOUNT_REQ;
 			nfs_send();
-- 
2.17.1

[U-Boot] [PATCH 2/4] nfs: factor out generic reply error handling

[Christian Gmeiner]

From: Thomas RIENOESSL <thomas.rienoessl@bachmann.info>

Signed-off-by: Thomas RIENOESSL <thomas.rienoessl@bachmann.info>
---
 net/nfs.c | 93 ++++++++++++++++++++++++++++++-------------------------
 1 file changed, 51 insertions(+), 42 deletions(-)

diff --git a/net/nfs.c b/net/nfs.c
index 81c08de626..d3de9b8c38 100644
--- a/net/nfs.c
+++ b/net/nfs.c
@@ -440,6 +440,54 @@ static void nfs_send(void)
 Handlers for the reply from server
 **************************************************************************/
 
+static int rpc_handle_error(struct rpc_t *rpc_pkt)
+{
+	if (rpc_pkt->u.reply.rstatus  ||
+	    rpc_pkt->u.reply.verifier ||
+	    rpc_pkt->u.reply.astatus  ||
+	    rpc_pkt->u.reply.data[0]) {
+		switch (ntohl(rpc_pkt->u.reply.astatus)) {
+		case NFS_RPC_SUCCESS: /* Not an error */
+			break;
+		case NFS_RPC_PROG_MISMATCH: {
+			/* Remote can't support NFS version */
+			const int min = ntohl(rpc_pkt->u.reply.data[0]);
+			const int max = ntohl(rpc_pkt->u.reply.data[1]);
+
+			if (max < NFS_V2 || max > NFS_V3 || min > NFS_V3) {
+				puts("*** ERROR: NFS version not supported");
+				debug(": Requested: V%d, accepted: min V%d - max V%d\n",
+				      choosen_nfs_version,
+				      ntohl(rpc_pkt->u.reply.data[0]),
+				      ntohl(rpc_pkt->u.reply.data[1]));
+				puts("\n");
+				choosen_nfs_version = NFS_UNKOWN;
+				break;
+			}
+
+			debug("*** Warning: NFS version not supported: Requested: V%d, accepted: min V%d - max V%d\n",
+					choosen_nfs_version,
+					ntohl(rpc_pkt->u.reply.data[0]),
+					ntohl(rpc_pkt->u.reply.data[1]));
+			debug("Will retry with NFSv%d\n", min);
+			choosen_nfs_version = min;
+			return -NFS_RPC_PROG_MISMATCH;
+		}
+		case NFS_RPC_PROG_UNAVAIL:
+		case NFS_RPC_PROC_UNAVAIL:
+		case NFS_RPC_GARBAGE_ARGS:
+		case NFS_RPC_SYSTEM_ERR:
+		default: /* Unknown error on 'accept state' flag */
+			debug("*** ERROR: accept state error (%d)\n",
+			      ntohl(rpc_pkt->u.reply.astatus));
+			break;
+		}
+		return -1;
+	}
+
+	return 0;
+}
+
 static int rpc_lookup_reply(int prog, uchar *pkt, unsigned len)
 {
 	struct rpc_t rpc_pkt;
@@ -533,48 +581,9 @@ static int nfs_lookup_reply(uchar *pkt, unsigned len)
 	else if (ntohl(rpc_pkt.u.reply.id) < rpc_id)
 		return -NFS_RPC_DROP;
 
-	if (rpc_pkt.u.reply.rstatus  ||
-	    rpc_pkt.u.reply.verifier ||
-	    rpc_pkt.u.reply.astatus  ||
-	    rpc_pkt.u.reply.data[0]) {
-		switch (ntohl(rpc_pkt.u.reply.astatus)) {
-		case NFS_RPC_SUCCESS: /* Not an error */
-			break;
-		case NFS_RPC_PROG_MISMATCH: {
-			/* Remote can't support NFS version */
-			const int min = ntohl(rpc_pkt.u.reply.data[0]);
-			const int max = ntohl(rpc_pkt.u.reply.data[1]);
-
-			if (max < NFS_V2 || max > NFS_V3 || min > NFS_V3) {
-				puts("*** ERROR: NFS version not supported");
-				debug(": Requested: V%d, accepted: min V%d - max V%d\n",
-				      choosen_nfs_version,
-				      ntohl(rpc_pkt.u.reply.data[0]),
-				      ntohl(rpc_pkt.u.reply.data[1]));
-				puts("\n");
-				choosen_nfs_version = NFS_UNKOWN;
-				break;
-			}
-
-			debug("*** Warning: NFS version not supported: Requested: V%d, accepted: min V%d - max V%d\n",
-					choosen_nfs_version,
-					ntohl(rpc_pkt.u.reply.data[0]),
-					ntohl(rpc_pkt.u.reply.data[1]));
-			debug("Will retry with NFSv%d\n", min);
-			choosen_nfs_version = min;
-			return -NFS_RPC_PROG_MISMATCH;
-		}
-		case NFS_RPC_PROG_UNAVAIL:
-		case NFS_RPC_PROC_UNAVAIL:
-		case NFS_RPC_GARBAGE_ARGS:
-		case NFS_RPC_SYSTEM_ERR:
-		default: /* Unknown error on 'accept state' flag */
-			debug("*** ERROR: accept state error (%d)\n",
-			      ntohl(rpc_pkt.u.reply.astatus));
-			break;
-		}
-		return -1;
-	}
+	int ret =  rpc_handle_error(&rpc_pkt);
+	if (ret)
+		return ret;
 
 	if (choosen_nfs_version == NFS_V2) {
 		memcpy(filefh, rpc_pkt.u.reply.data + 1, NFS_FHSIZE);
-- 
2.17.1

[U-Boot] [PATCH 3/4] nfs: handle rpc errors for mount calls

[Christian Gmeiner]

From: Thomas RIENOESSL <thomas.rienoessl@bachmann.info>

Signed-off-by: Thomas RIENOESSL <thomas.rienoessl@bachmann.info>
---
 net/nfs.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

diff --git a/net/nfs.c b/net/nfs.c
index d3de9b8c38..bd6588fe42 100644
--- a/net/nfs.c
+++ b/net/nfs.c
@@ -531,11 +531,9 @@ static int nfs_mount_reply(uchar *pkt, unsigned len)
 	else if (ntohl(rpc_pkt.u.reply.id) < rpc_id)
 		return -NFS_RPC_DROP;
 
-	if (rpc_pkt.u.reply.rstatus  ||
-	    rpc_pkt.u.reply.verifier ||
-	    rpc_pkt.u.reply.astatus  ||
-	    rpc_pkt.u.reply.data[0])
-		return -1;
+	int ret =  rpc_handle_error(&rpc_pkt);
+	if (ret)
+		return ret;
 
 	fs_mounted = 1;
 	/*  NFSv2 and NFSv3 use same structure */
@@ -779,6 +777,10 @@ static void nfs_handler(uchar *pkt, unsigned dest, struct in_addr sip,
 			/* just to be sure... */
 			nfs_state = STATE_UMOUNT_REQ;
 			nfs_send();
+		} else if (reply == -NFS_RPC_PROG_MISMATCH &&
+			   choosen_nfs_version != NFS_UNKOWN) {
+			nfs_state = STATE_MOUNT_REQ;
+			nfs_send();
 		} else {
 			nfs_state = STATE_LOOKUP_REQ;
 			nfs_send();
-- 
2.17.1

[U-Boot] [PATCH 4/4] net: add NFSv1 support

[Christian Gmeiner]

From: Thomas RIENOESSL <thomas.rienoessl@bachmann.info>

NFSv1 support added by Christian Gmeiner, Thomas Rienoessl,
September 27, 2018. As of now, NFSv3 is the default choice.
if the server does not support NFSv3, we fall back to
versions 2 or 1.

Signed-off-by: Thomas RIENOESSL <thomas.rienoessl@bachmann.info>
---
 net/nfs.c | 42 +++++++++++++++++++++++++++++++++---------
 1 file changed, 33 insertions(+), 9 deletions(-)

diff --git a/net/nfs.c b/net/nfs.c
index bd6588fe42..fd1b5e0715 100644
--- a/net/nfs.c
+++ b/net/nfs.c
@@ -26,6 +26,10 @@
  * NFSv2 is still used by default. But if server does not support NFSv2, then
  * NFSv3 is used, if available on NFS server. */
 
+/* NOTE 5: NFSv1 support added by Christian Gmeiner, Thomas Rienoessl,
+ * September 27, 2018. As of now, NFSv3 is the default choice. If the server
+ * does not support NFSv3, we fall back to versions 2 or 1. */
+
 #include <common.h>
 #include <command.h>
 #include <net.h>
@@ -76,6 +80,7 @@ static char nfs_path_buff[2048];
 
 enum nfs_version {
 	NFS_UNKOWN = 0,
+	NFS_V1 = 1,
 	NFS_V2 = 2,
 	NFS_V3 = 3,
 };
@@ -189,6 +194,7 @@ static void rpc_req(int rpc_prog, int rpc_proc, uint32_t *data, int datalen)
 	switch (rpc_prog) {
 	case PROG_NFS:
 		switch (choosen_nfs_version) {
+		case NFS_V1:
 		case NFS_V2:
 			rpc_pkt.u.call.vers = htonl(2);
 			break;
@@ -202,8 +208,26 @@ static void rpc_req(int rpc_prog, int rpc_proc, uint32_t *data, int datalen)
 			break;
 		}
 		break;
-	case PROG_PORTMAP:
 	case PROG_MOUNT:
+		switch (choosen_nfs_version) {
+		case NFS_V1:
+			rpc_pkt.u.call.vers = htonl(1);
+			break;
+
+		case NFS_V2:
+			rpc_pkt.u.call.vers = htonl(2);
+			break;
+
+		case NFS_V3:
+			rpc_pkt.u.call.vers = htonl(3);
+			break;
+
+		case NFS_UNKOWN:
+			/* nothing to do */
+			break;
+		}
+		break;
+	case PROG_PORTMAP:
 	default:
 		rpc_pkt.u.call.vers = htonl(2);	/* portmapper is version 2 */
 	}
@@ -308,7 +332,7 @@ static void nfs_readlink_req(void)
 	p = &(data[0]);
 	p = rpc_add_credentials(p);
 
-	if (choosen_nfs_version == NFS_V2) {
+	if (choosen_nfs_version != NFS_V3) {
 		memcpy(p, filefh, NFS_FHSIZE);
 		p += (NFS_FHSIZE / 4);
 	} else { /* NFSV3_FLAG */
@@ -337,7 +361,7 @@ static void nfs_lookup_req(char *fname)
 	p = &(data[0]);
 	p = rpc_add_credentials(p);
 
-	if (choosen_nfs_version == NFS_V2) {
+	if (choosen_nfs_version != NFS_V3) {
 		memcpy(p, dirfh, NFS_FHSIZE);
 		p += (NFS_FHSIZE / 4);
 		*p++ = htonl(fnamelen);
@@ -377,7 +401,7 @@ static void nfs_read_req(int offset, int readlen)
 	p = &(data[0]);
 	p = rpc_add_credentials(p);
 
-	if (choosen_nfs_version == NFS_V2) {
+	if (choosen_nfs_version != NFS_V3) {
 		memcpy(p, filefh, NFS_FHSIZE);
 		p += (NFS_FHSIZE / 4);
 		*p++ = htonl(offset);
@@ -407,13 +431,13 @@ static void nfs_send(void)
 
 	switch (nfs_state) {
 	case STATE_PRCLOOKUP_PROG_MOUNT_REQ:
-		if (choosen_nfs_version == NFS_V2)
+		if (choosen_nfs_version != NFS_V3)
 			rpc_lookup_req(PROG_MOUNT, 1);
 		else  /* NFSV3_FLAG */
 			rpc_lookup_req(PROG_MOUNT, 3);
 		break;
 	case STATE_PRCLOOKUP_PROG_NFS_REQ:
-		if (choosen_nfs_version == NFS_V2)
+		if (choosen_nfs_version != NFS_V3)
 			rpc_lookup_req(PROG_NFS, 2);
 		else  /* NFSV3_FLAG */
 			rpc_lookup_req(PROG_NFS, 3);
@@ -454,7 +478,7 @@ static int rpc_handle_error(struct rpc_t *rpc_pkt)
 			const int min = ntohl(rpc_pkt->u.reply.data[0]);
 			const int max = ntohl(rpc_pkt->u.reply.data[1]);
 
-			if (max < NFS_V2 || max > NFS_V3 || min > NFS_V3) {
+			if (max < NFS_V1 || max > NFS_V3 || min > NFS_V3) {
 				puts("*** ERROR: NFS version not supported");
 				debug(": Requested: V%d, accepted: min V%d - max V%d\n",
 				      choosen_nfs_version,
@@ -583,7 +607,7 @@ static int nfs_lookup_reply(uchar *pkt, unsigned len)
 	if (ret)
 		return ret;
 
-	if (choosen_nfs_version == NFS_V2) {
+	if (choosen_nfs_version != NFS_V3) {
 		memcpy(filefh, rpc_pkt.u.reply.data + 1, NFS_FHSIZE);
 	} else {  /* NFSV3_FLAG */
 		filefh3_length = ntohl(rpc_pkt.u.reply.data[1]);
@@ -702,7 +726,7 @@ static int nfs_read_reply(uchar *pkt, unsigned len)
 	if (!(nfs_offset % ((NFS_READ_SIZE / 2) * 10)))
 		putc('#');
 
-	if (choosen_nfs_version == NFS_V2) {
+	if (choosen_nfs_version != NFS_V3) {
 		rlen = ntohl(rpc_pkt.u.reply.data[18]);
 		data_ptr = (uchar *)&(rpc_pkt.u.reply.data[19]);
 	} else {  /* NFSV3_FLAG */
-- 
2.17.1

[U-Boot] [PATCH 1/4] nfs: convert supported_nfs_versions bitfield to an enum

[Wolfgang Denk]

Dear Christian,

In message <20181001094646.11539-1-christian.gmeiner@gmail.com> you wrote:
> From: Thomas RIENOESSL <thomas.rienoessl@bachmann.info>
> 
> Prep. work to support nfs v1.

Hm... as you are putting efforts into NFS support...

Here comes a more general question:

I wonder if it's worth the work on NFS at all, or if we should
remove NFS support from U-Boot alltogether?

1) We support only NFS v2 (and v3) in U-Boot, and most standard Linux
   distros support only v4 in their default configurations.

2) We support only UDP, but most standard Linux distros support only
   TCP in their default configurations (see [1])

   [1] http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=fbd7623dd8d5e418e7cb369d4026d5368f7c46a6

Try a NFS download from any recent Linux distro (i. e. one including
nfs-utils 2.3.1 or later)...


I feel a half-way solution is unsatisfactory, but the way for the
Real Thing (TM) is a pretty long one...

The fact that nobody compained yet that NFS stopped working fo him
suggests that there are only very, very few users of NFS at all.
If one of these is willing to step up and fix this for real, he is
of course more than welcome.  But if not - should we not remove the
more or less obsolete code?

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Microsoft Multitasking:
                     several applications can crash at the same time.

[U-Boot] [PATCH 1/4] nfs: convert supported_nfs_versions bitfield to an enum

[Christian Gmeiner]

Hi Wolfgang

>
> In message <20181001094646.11539-1-christian.gmeiner@gmail.com> you wrote:
> > From: Thomas RIENOESSL <thomas.rienoessl@bachmann.info>
> >
> > Prep. work to support nfs v1.
>
> Hm... as you are putting efforts into NFS support...
>
> Here comes a more general question:
>
> I wonder if it's worth the work on NFS at all, or if we should
> remove NFS support from U-Boot alltogether?
>
> 1) We support only NFS v2 (and v3) in U-Boot, and most standard Linux
>    distros support only v4 in their default configurations.
>

Linux is not the only operating system used in the world. My NFSv1
server runs on a vxWorks 5 device which
I need to support - sadly.

> 2) We support only UDP, but most standard Linux distros support only
>    TCP in their default configurations (see [1])
>
>    [1] http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=fbd7623dd8d5e418e7cb369d4026d5368f7c46a6
>
> Try a NFS download from any recent Linux distro (i. e. one including
> nfs-utils 2.3.1 or later)...
>

That is true.

>
> I feel a half-way solution is unsatisfactory, but the way for the
> Real Thing (TM) is a pretty long one...
>
> The fact that nobody compained yet that NFS stopped working fo him
> suggests that there are only very, very few users of NFS at all.
> If one of these is willing to step up and fix this for real, he is
> of course more than welcome.  But if not - should we not remove the
> more or less obsolete code?
>

As u-boot is lacking TCP support this is quite a challenging task. I
have seen some work in progress
patches, which I have reviewed and hoped that it helps to get them
further. I am also
interested in using ftp directly in u-boot. At the moment we are using
uip as tcp stack and hacked
together a ftp client.

If you want to remove nfs all together I need to keep nfs in our
downstream repo which is kinda sad but
doable.

-- 
greets
--
Christian Gmeiner, MSc

https://christian-gmeiner.info

[U-Boot] [PATCH 1/4] nfs: convert supported_nfs_versions bitfield to an enum

[Joe Hershberger]

Hi Christian,

On Mon, Oct 1, 2018 at 8:57 AM Christian Gmeiner
<christian.gmeiner@gmail.com> wrote:
>
> Hi Wolfgang
>
> >
> > In message <20181001094646.11539-1-christian.gmeiner@gmail.com> you wrote:
> > > From: Thomas RIENOESSL <thomas.rienoessl@bachmann.info>
> > >
> > > Prep. work to support nfs v1.
> >
> > Hm... as you are putting efforts into NFS support...
> >
> > Here comes a more general question:
> >
> > I wonder if it's worth the work on NFS at all, or if we should
> > remove NFS support from U-Boot alltogether?
> >
> > 1) We support only NFS v2 (and v3) in U-Boot, and most standard Linux
> >    distros support only v4 in their default configurations.
> >
>
> Linux is not the only operating system used in the world. My NFSv1
> server runs on a vxWorks 5 device which
> I need to support - sadly.
>
> > 2) We support only UDP, but most standard Linux distros support only
> >    TCP in their default configurations (see [1])
> >
> >    [1] http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=fbd7623dd8d5e418e7cb369d4026d5368f7c46a6
> >
> > Try a NFS download from any recent Linux distro (i. e. one including
> > nfs-utils 2.3.1 or later)...
> >
>
> That is true.
>
> >
> > I feel a half-way solution is unsatisfactory, but the way for the
> > Real Thing (TM) is a pretty long one...
> >
> > The fact that nobody compained yet that NFS stopped working fo him
> > suggests that there are only very, very few users of NFS at all.
> > If one of these is willing to step up and fix this for real, he is
> > of course more than welcome.  But if not - should we not remove the
> > more or less obsolete code?
> >
>
> As u-boot is lacking TCP support this is quite a challenging task. I
> have seen some work in progress
> patches, which I have reviewed and hoped that it helps to get them
> further.

I'm trying to get those patches into a state that they are acceptable,
but currently they are pretty brittle. I've not actually seen them
work, though the contributor says they do in some case. I had to do
some work to have the series just not break UDP functionality, so we
have more work to do there.

> I am also
> interested in using ftp directly in u-boot. At the moment we are using
> uip as tcp stack and hacked
> together a ftp client.

I was contemplating if using something like that or lwip would be
better than rolling our own, but my concern is both how configurable
those stacks are to make them lean as well as adding an external
dependency / forking their code into our repo. Not excited about
either.

> If you want to remove nfs all together I need to keep nfs in our
> downstream repo which is kinda sad but
> doable.

I think that if it is in use by you, then it's ok to keep around...
especially if you are contributing to make it more capable. I would
ask that you come up with a way to test the functionality in one of
the travis tests.

Cheers,
-Joe

> --
> greets
> --
> Christian Gmeiner, MSc
>
> https://christian-gmeiner.info
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/4] nfs: convert supported_nfs_versions bitfield to an enum

[Simon Goldschmidt]

On 22.10.2018 20:53, Joe Hershberger wrote:
> Hi Christian,
>
> On Mon, Oct 1, 2018 at 8:57 AM Christian Gmeiner
> <christian.gmeiner@gmail.com> wrote:
>> Hi Wolfgang
>>
>>> In message <20181001094646.11539-1-christian.gmeiner@gmail.com> you wrote:
>>>> From: Thomas RIENOESSL <thomas.rienoessl@bachmann.info>
>>>>
>>>> Prep. work to support nfs v1.
>>> Hm... as you are putting efforts into NFS support...
>>>
>>> Here comes a more general question:
>>>
>>> I wonder if it's worth the work on NFS at all, or if we should
>>> remove NFS support from U-Boot alltogether?
>>>
>>> 1) We support only NFS v2 (and v3) in U-Boot, and most standard Linux
>>>     distros support only v4 in their default configurations.
>>>
>> Linux is not the only operating system used in the world. My NFSv1
>> server runs on a vxWorks 5 device which
>> I need to support - sadly.
>>
>>> 2) We support only UDP, but most standard Linux distros support only
>>>     TCP in their default configurations (see [1])
>>>
>>>     [1] http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=fbd7623dd8d5e418e7cb369d4026d5368f7c46a6
>>>
>>> Try a NFS download from any recent Linux distro (i. e. one including
>>> nfs-utils 2.3.1 or later)...
>>>
>> That is true.
>>
>>> I feel a half-way solution is unsatisfactory, but the way for the
>>> Real Thing (TM) is a pretty long one...
>>>
>>> The fact that nobody compained yet that NFS stopped working fo him
>>> suggests that there are only very, very few users of NFS at all.
>>> If one of these is willing to step up and fix this for real, he is
>>> of course more than welcome.  But if not - should we not remove the
>>> more or less obsolete code?
>>>
>> As u-boot is lacking TCP support this is quite a challenging task. I
>> have seen some work in progress
>> patches, which I have reviewed and hoped that it helps to get them
>> further.
> I'm trying to get those patches into a state that they are acceptable,
> but currently they are pretty brittle. I've not actually seen them
> work, though the contributor says they do in some case. I had to do
> some work to have the series just not break UDP functionality, so we
> have more work to do there.
>
>> I am also
>> interested in using ftp directly in u-boot. At the moment we are using
>> uip as tcp stack and hacked
>> together a ftp client.
> I was contemplating if using something like that or lwip would be
> better than rolling our own, but my concern is both how configurable
> those stacks are to make them lean as well as adding an external
> dependency / forking their code into our repo. Not excited about
> either.

As the maintainer of lwIP, I already have thought about this more than 
once. My main concern however was the license (lwIP is BSD style) and 
the fact that it expects to always run (I don't know the U-Boot network 
stack that well, but it only runs when called, doesn't it?).

Forking is never a good idea with open source projects. We try to 
integrate as much back into the mainline code as possible. Although we 
of course depend on the people using the stack to contribute things back.

Of course I don't want to push anyone (and I don't want to load myself 
with more work), but I could offer some help in getting it to run if 
anyone had a real interest. Configuration shouldn't be too much of an issue.

Given the systems U-Boot runs on, lwIP would definitively be a better 
choice than uIP if you have performance improvements of tcp in mind.

[BTW: a http client (a.k.a. 'wget') is already included in lwIP and with 
help of a 3rd party TLS library, it even provides HTTPS support]


Simon

[U-Boot] [PATCH 1/4] nfs: convert supported_nfs_versions bitfield to an enum

[Joe Hershberger]

On Mon, Oct 22, 2018 at 2:40 PM Simon Goldschmidt
<simon.k.r.goldschmidt@gmail.com> wrote:
>
> On 22.10.2018 20:53, Joe Hershberger wrote:
> > Hi Christian,
> >
> > On Mon, Oct 1, 2018 at 8:57 AM Christian Gmeiner
> > <christian.gmeiner@gmail.com> wrote:
> >> Hi Wolfgang
> >>
> >>> In message <20181001094646.11539-1-christian.gmeiner@gmail.com> you wrote:
> >>>> From: Thomas RIENOESSL <thomas.rienoessl@bachmann.info>
> >>>>
> >>>> Prep. work to support nfs v1.
> >>> Hm... as you are putting efforts into NFS support...
> >>>
> >>> Here comes a more general question:
> >>>
> >>> I wonder if it's worth the work on NFS at all, or if we should
> >>> remove NFS support from U-Boot alltogether?
> >>>
> >>> 1) We support only NFS v2 (and v3) in U-Boot, and most standard Linux
> >>>     distros support only v4 in their default configurations.
> >>>
> >> Linux is not the only operating system used in the world. My NFSv1
> >> server runs on a vxWorks 5 device which
> >> I need to support - sadly.
> >>
> >>> 2) We support only UDP, but most standard Linux distros support only
> >>>     TCP in their default configurations (see [1])
> >>>
> >>>     [1] http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=fbd7623dd8d5e418e7cb369d4026d5368f7c46a6
> >>>
> >>> Try a NFS download from any recent Linux distro (i. e. one including
> >>> nfs-utils 2.3.1 or later)...
> >>>
> >> That is true.
> >>
> >>> I feel a half-way solution is unsatisfactory, but the way for the
> >>> Real Thing (TM) is a pretty long one...
> >>>
> >>> The fact that nobody compained yet that NFS stopped working fo him
> >>> suggests that there are only very, very few users of NFS at all.
> >>> If one of these is willing to step up and fix this for real, he is
> >>> of course more than welcome.  But if not - should we not remove the
> >>> more or less obsolete code?
> >>>
> >> As u-boot is lacking TCP support this is quite a challenging task. I
> >> have seen some work in progress
> >> patches, which I have reviewed and hoped that it helps to get them
> >> further.
> > I'm trying to get those patches into a state that they are acceptable,
> > but currently they are pretty brittle. I've not actually seen them
> > work, though the contributor says they do in some case. I had to do
> > some work to have the series just not break UDP functionality, so we
> > have more work to do there.
> >
> >> I am also
> >> interested in using ftp directly in u-boot. At the moment we are using
> >> uip as tcp stack and hacked
> >> together a ftp client.
> > I was contemplating if using something like that or lwip would be
> > better than rolling our own, but my concern is both how configurable
> > those stacks are to make them lean as well as adding an external
> > dependency / forking their code into our repo. Not excited about
> > either.
>
> As the maintainer of lwIP, I already have thought about this more than
> once. My main concern however was the license (lwIP is BSD style) and

Yes, the license is a concern. I'm not a lawyer, but maybe someone can
comment on what our options are here. Wolfgang? Tom?

> the fact that it expects to always run (I don't know the U-Boot network
> stack that well, but it only runs when called, doesn't it?).

Yes, it currently works that way... it is pretty aggressive about
going away. That is something that I've wanted to rework for a while,
but haven't gotten to it. It certainly has no threads so nothing
persists. Only if you are calling into a command that uses the network
stack do you have the ability to do networking.

>
> Forking is never a good idea with open source projects. We try to
> integrate as much back into the mainline code as possible. Although we
> of course depend on the people using the stack to contribute things back.

Yes, though due to the low-level nature of U-Boot, it seems that
forking while changing as little as reasonable is the approach we've
taken in all cases I've seen in the past. Much like the bits of Linux
that are included, the forks strongly encourage changes to first be
sent to the main project, so as to support the mainline project and to
make upgrades from the mainline project much easier.

>
> Of course I don't want to push anyone (and I don't want to load myself
> with more work), but I could offer some help in getting it to run if
> anyone had a real interest. Configuration shouldn't be too much of an issue.

That's good to hear.

>
> Given the systems U-Boot runs on, lwIP would definitively be a better
> choice than uIP if you have performance improvements of tcp in mind.

That was my instinct... glad to hear from you.

>
> [BTW: a http client (a.k.a. 'wget') is already included in lwIP and with
> help of a 3rd party TLS library, it even provides HTTPS support]

Excellent.

>
>
> Simon
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> https://lists.denx.de/listinfo/u-boot

[U-Boot] [PATCH 1/4] nfs: convert supported_nfs_versions bitfield to an enum

[Tom Rini]

On Mon, Oct 29, 2018 at 08:13:37PM +0000, Joe Hershberger wrote:
> On Mon, Oct 22, 2018 at 2:40 PM Simon Goldschmidt
> <simon.k.r.goldschmidt@gmail.com> wrote:
> >
> > On 22.10.2018 20:53, Joe Hershberger wrote:
> > > Hi Christian,
> > >
> > > On Mon, Oct 1, 2018 at 8:57 AM Christian Gmeiner
> > > <christian.gmeiner@gmail.com> wrote:
> > >> Hi Wolfgang
> > >>
> > >>> In message <20181001094646.11539-1-christian.gmeiner@gmail.com> you wrote:
> > >>>> From: Thomas RIENOESSL <thomas.rienoessl@bachmann.info>
> > >>>>
> > >>>> Prep. work to support nfs v1.
> > >>> Hm... as you are putting efforts into NFS support...
> > >>>
> > >>> Here comes a more general question:
> > >>>
> > >>> I wonder if it's worth the work on NFS at all, or if we should
> > >>> remove NFS support from U-Boot alltogether?
> > >>>
> > >>> 1) We support only NFS v2 (and v3) in U-Boot, and most standard Linux
> > >>>     distros support only v4 in their default configurations.
> > >>>
> > >> Linux is not the only operating system used in the world. My NFSv1
> > >> server runs on a vxWorks 5 device which
> > >> I need to support - sadly.
> > >>
> > >>> 2) We support only UDP, but most standard Linux distros support only
> > >>>     TCP in their default configurations (see [1])
> > >>>
> > >>>     [1] http://git.linux-nfs.org/?p=steved/nfs-utils.git;a=commitdiff;h=fbd7623dd8d5e418e7cb369d4026d5368f7c46a6
> > >>>
> > >>> Try a NFS download from any recent Linux distro (i. e. one including
> > >>> nfs-utils 2.3.1 or later)...
> > >>>
> > >> That is true.
> > >>
> > >>> I feel a half-way solution is unsatisfactory, but the way for the
> > >>> Real Thing (TM) is a pretty long one...
> > >>>
> > >>> The fact that nobody compained yet that NFS stopped working fo him
> > >>> suggests that there are only very, very few users of NFS at all.
> > >>> If one of these is willing to step up and fix this for real, he is
> > >>> of course more than welcome.  But if not - should we not remove the
> > >>> more or less obsolete code?
> > >>>
> > >> As u-boot is lacking TCP support this is quite a challenging task. I
> > >> have seen some work in progress
> > >> patches, which I have reviewed and hoped that it helps to get them
> > >> further.
> > > I'm trying to get those patches into a state that they are acceptable,
> > > but currently they are pretty brittle. I've not actually seen them
> > > work, though the contributor says they do in some case. I had to do
> > > some work to have the series just not break UDP functionality, so we
> > > have more work to do there.
> > >
> > >> I am also
> > >> interested in using ftp directly in u-boot. At the moment we are using
> > >> uip as tcp stack and hacked
> > >> together a ftp client.
> > > I was contemplating if using something like that or lwip would be
> > > better than rolling our own, but my concern is both how configurable
> > > those stacks are to make them lean as well as adding an external
> > > dependency / forking their code into our repo. Not excited about
> > > either.
> >
> > As the maintainer of lwIP, I already have thought about this more than
> > once. My main concern however was the license (lwIP is BSD style) and
> 
> Yes, the license is a concern. I'm not a lawyer, but maybe someone can
> comment on what our options are here. Wolfgang? Tom?

We have BSD-2 and BSD-3 clause code today in the tree, usually because
we've had need to bring in existing code under such license.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20181029/084e2b03/attachment.sig>

[U-Boot] [PATCH 1/4] nfs: convert supported_nfs_versions bitfield to an enum

[Wolfgang Denk]

Dear Joe,

In message <CANr=Z=a1+UFV+gU=3a5wPz7UpH-mzsvB-+FZd=LD8JTXR3gRGg@mail.gmail.com> you wrote:
>
> > As the maintainer of lwIP, I already have thought about this more than
> > once. My main concern however was the license (lwIP is BSD style) and
> 
> Yes, the license is a concern. I'm not a lawyer, but maybe someone can
> comment on what our options are here. Wolfgang? Tom?

IANAL...

Fact is, we already have some 80+ source files in U-Boot which are
covered by the BSD-3-Clause license.  Apparently there are also
statements from the FSF that BSD-3-Clause is considered compatible
with GPLv2.

My _personal_ opinion is that I try to avoid BSD-3-Clause because of
both the:

        2. Redistributions in binary form must reproduce the above
           copyright notice, this list of conditions and the
           following disclaimer in the documentation and/or other
           materials provided with the distribution.

and the 

        3. The name of the author may not be used to endorse or
           promote products derived from this software without
           specific prior written permission.

clauses.

The former forces me to add "some text" to all documentation, and
the latter forbids me to say who wrote the code as this might be
considered promotion of the product.  Both are obligations I have
to adhere to, while GPL clearly says "You may not impose any further
restrictions on the recipients' exercise of the rights granted
herein."  So in my opinion BSD-3-Clause should be avoided - but
then, this is just my $0.02 - YMMV.

I take chances to have lwIP relicenced under a dual license (GPLv2
OR BSD-3-Clause) are epsilon?


Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,      Managing Director: Wolfgang Denk
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
A Freudian slip is when you say one thing but mean your mother.

[U-Boot] [PATCH 1/4] nfs: convert supported_nfs_versions bitfield to an enum

[Simon Goldschmidt]

Wolfgang Denk <wd@denx.de> schrieb am Di., 30. Okt. 2018, 09:46:

> Dear Joe,
>
> In message <CANr=Z=a1+UFV+gU=3a5wPz7UpH-mzsvB-+FZd=
> LD8JTXR3gRGg at mail.gmail.com> you wrote:
> >
> > > As the maintainer of lwIP, I already have thought about this more than
> > > once. My main concern however was the license (lwIP is BSD style) and
> >
> > Yes, the license is a concern. I'm not a lawyer, but maybe someone can
> > comment on what our options are here. Wolfgang? Tom?
>
> IANAL...
>
> Fact is, we already have some 80+ source files in U-Boot which are
> covered by the BSD-3-Clause license.  Apparently there are also
> statements from the FSF that BSD-3-Clause is considered compatible
> with GPLv2.
>
> My _personal_ opinion is that I try to avoid BSD-3-Clause because of
> both the:
>
>         2. Redistributions in binary form must reproduce the above
>            copyright notice, this list of conditions and the
>            following disclaimer in the documentation and/or other
>            materials provided with the distribution.
>
> and the
>
>         3. The name of the author may not be used to endorse or
>            promote products derived from this software without
>            specific prior written permission.
>
> clauses.
>
> The former forces me to add "some text" to all documentation, and
> the latter forbids me to say who wrote the code as this might be
> considered promotion of the product.  Both are obligations I have
> to adhere to, while GPL clearly says "You may not impose any further
> restrictions on the recipients' exercise of the rights granted
> herein."  So in my opinion BSD-3-Clause should be avoided - but
> then, this is just my $0.02 - YMMV.
>
> I take chances to have lwIP relicenced under a dual license (GPLv2
> OR BSD-3-Clause) are epsilon?
>

Given that I am not the only author but lwIP has a long history of
contributors, I don't know how I should handle such a license change...

Simon