nfs: convert supported_nfs_versions bitfield to an enum

PATCH New Christian Gmeiner 5 participants 12 messages Oct 1, 2018 – Oct 30, 2018 Networking

lore

Share & tools

lore

Christian Gmeiner

author

2018-10-01 09:46 UTC #0 lore raw

PATCH 1/4 nfs: convert supported_nfs_versions bitfield to an enum

From: Thomas RIENOESSL <[email protected]>

Prep. work to support nfs v1.

Signed-off-by Thomas RIENOESSL <[email protected]>

---
 net/nfs.c | 79 +++++++++++++++++++++++++++++++------------------------
 1 file changed, 45 insertions(+), 34 deletions(-)

net/nfs.c +45 ~~-34~~

index d6a7f8e827..81c08de626 100644
@@ -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();

Signature · 1 line

2.17.1

Christian Gmeiner

author

2018-10-01 09:46 UTC #1 lore raw

PATCH 2/4 nfs: factor out generic reply error handling

From: Thomas RIENOESSL <[email protected]>

Signed-off-by Thomas RIENOESSL <[email protected]>

---
 net/nfs.c | 93 ++++++++++++++++++++++++++++++-------------------------
 1 file changed, 51 insertions(+), 42 deletions(-)

net/nfs.c +51 ~~-42~~

index 81c08de626..d3de9b8c38 100644
@@ -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);

Signature · 1 line

2.17.1

Christian Gmeiner

author

2018-10-01 09:46 UTC #2 lore raw

PATCH 3/4 nfs: handle rpc errors for mount calls

In reply to Christian Gmeiner

From: Thomas RIENOESSL <[email protected]>

Signed-off-by Thomas RIENOESSL <[email protected]>

---
 net/nfs.c | 12 +++++++-----
 1 file changed, 7 insertions(+), 5 deletions(-)

net/nfs.c +7 -5

index d3de9b8c38..bd6588fe42 100644
@@ -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();

Signature · 1 line

2.17.1

Christian Gmeiner

author

2018-10-01 09:46 UTC #3 lore raw

PATCH 4/4 net: add NFSv1 support

In reply to Christian Gmeiner

From: Thomas RIENOESSL <[email protected]>

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 <[email protected]>

---
 net/nfs.c | 42 +++++++++++++++++++++++++++++++++---------
 1 file changed, 33 insertions(+), 9 deletions(-)

net/nfs.c +33 -9

index bd6588fe42..fd1b5e0715 100644
@@ -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 */

Signature · 1 line

2.17.1

Wolfgang Denk

2018-10-01 13:08 UTC #4 lore raw

PATCH 1/4 nfs: convert supported_nfs_versions bitfield to an enum

In reply to Christian Gmeiner

Dear Christian,

Quoted 3 lines · In message <[email protected]> you wrote:

From: Thomas RIENOESSL <[email protected]>
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

Signature · 5 lines

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.

Christian Gmeiner

author

2018-10-01 13:56 UTC #5 lore raw

PATCH 1/4 nfs: convert supported_nfs_versions bitfield to an enum

Hi Wolfgang

Quoted 8 lines

Quoted 3 lines · In message <[email protected]> you wrote:
From: Thomas RIENOESSL <[email protected]>
Prep. work to support nfs v1.
Hm... as you are putting efforts into NFS support...

Quoted 8 lines

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.

Quoted 8 lines

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.

Quoted 10 lines

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.

Signature · 5 lines

greets
--
Christian Gmeiner, MSc

https://christian-gmeiner.info

Joe Hershberger

2018-10-22 18:53 UTC #6 lore raw

PATCH 1/4 nfs: convert supported_nfs_versions bitfield to an enum

Hi Christian,

Quoted 46 lines · Christian Gmeiner

Hi Wolfgang
Quoted 8 lines
Quoted 3 lines · In message <[email protected]> you wrote:
From: Thomas RIENOESSL <[email protected]>
Prep. work to support nfs v1.
Hm... as you are putting efforts into NFS support...
Quoted 8 lines
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.
Quoted 8 lines
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.
Quoted 10 lines
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?

Quoted 4 lines

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.

Quoted 4 lines

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.

Quoted 3 lines

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

Quoted 10 lines

--
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

Simon Goldschmidt

2018-10-22 19:39 UTC #7 lore raw

PATCH 1/4 nfs: convert supported_nfs_versions bitfield to an enum

Quoted 57 lines · Joe Hershberger

Hi Christian,
Quoted 39 lines · Christian Gmeiner
Hi Wolfgang
Quoted 6 lines
Quoted 3 lines · In message <[email protected]> you wrote:
From: Thomas RIENOESSL <[email protected]>
Prep. work to support nfs v1.
Hm... as you are putting efforts into NFS support...
Quoted 8 lines
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.
Quoted 8 lines
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.
Quoted 9 lines
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?
Quoted 4 lines
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.
Quoted 4 lines
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.

Quoted 5 lines

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

Joe Hershberger

2018-10-29 20:05 UTC #8 lore raw

PATCH 1/4 nfs: convert supported_nfs_versions bitfield to an enum

Quoted 59 lines · Simon Goldschmidt

Quoted 57 lines · Joe Hershberger
Hi Christian,
Quoted 39 lines · Christian Gmeiner
Hi Wolfgang
Quoted 6 lines
Quoted 3 lines · In message <[email protected]> you wrote:
From: Thomas RIENOESSL <[email protected]>
Prep. work to support nfs v1.
Hm... as you are putting efforts into NFS support...
Quoted 8 lines
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.
Quoted 8 lines
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.
Quoted 9 lines
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?
Quoted 4 lines
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.
Quoted 4 lines
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.

Quoted 8 lines

Quoted 5 lines
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?

Quoted 2 lines

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.

Quoted 4 lines

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.

Quoted 4 lines

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.

Quoted 3 lines

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.

Quoted 3 lines

[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.

Quoted 7 lines

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

Tom Rini

2018-10-29 22:13 UTC #9 lore raw

PATCH 1/4 nfs: convert supported_nfs_versions bitfield to an enum

Quoted 67 lines · Joe Hershberger

Quoted 65 lines · Simon Goldschmidt
Quoted 62 lines · Joe Hershberger
Hi Christian,
Quoted 39 lines · Christian Gmeiner
Hi Wolfgang
Quoted 6 lines
Quoted 3 lines · In message <[email protected]> you wrote:
From: Thomas RIENOESSL <[email protected]>
Prep. work to support nfs v1.
Hm... as you are putting efforts into NFS support...
Quoted 8 lines
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.
Quoted 8 lines
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.
Quoted 9 lines
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?
Quoted 4 lines
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.
Quoted 4 lines
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.

Quoted 5 lines

Quoted 2 lines
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.

Signature · 8 lines

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>

Wolfgang Denk

2018-10-30 08:46 UTC #10 lore raw

PATCH 1/4 nfs: convert supported_nfs_versions bitfield to an enum

In reply to Joe Hershberger

Dear Joe,

Quoted 6 lines · In message <CANr=Z=a1+UFV+gU=3a5wPz7UpH-mzsvB-+FZd=LD8JTXR3gRGg@mail.gmail.com>…

Quoted 3 lines
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

Signature · 4 lines

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.

Simon Goldschmidt

2018-10-30 08:53 UTC #11 lore raw

PATCH 1/4 nfs: convert supported_nfs_versions bitfield to an enum

Wolfgang Denk <[email protected]> schrieb am Di., 30. Okt. 2018, 09:46:

Quoted 42 lines

Dear Joe,
In message <CANr=Z=a1+UFV+gU=3a5wPz7UpH-mzsvB-+FZd=
Quoted 6 lines · LD8JTXR3gRGg at mail.gmail.com> you wrote:
Quoted 3 lines
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.

Quoted 3 lines

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