[U-Boot] [PATCH 1/4] nfs: convert supported_nfs_versions bitfield to an enum
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();
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);
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();
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 */
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=fbd7623dd8d5...
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
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?
- 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.
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=fbd7623dd8d5...
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.
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?
- 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.
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=fbd7623dd8d5...
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@lists.denx.de https://lists.denx.de/listinfo/u-boot
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?
- 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.
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=fbd7623dd8d5...
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
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?
- 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.
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=fbd7623dd8d5...
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@lists.denx.de https://lists.denx.de/listinfo/u-boot
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?
- 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.
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=fbd7623dd8d5...
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.
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
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@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
participants (5)
-
Christian Gmeiner -
Joe Hershberger -
Simon Goldschmidt -
Tom Rini -
Wolfgang Denk