On Fri, Feb 07, 2014 at 10:50:56AM +0100, Jean-Christophe PLAGNIOL-VILLARD wrote:
> On 09:52 Fri 07 Feb , Uwe Kleine-K??nig wrote:
> > > > + npriv->rootfh_len = ntohl(net_read_uint32(p++));
> > > > + if (npriv->rootfh_len > NFS3_FHSIZE) {
> > > > + printf("%s: file handle too big: %lu\n", __func__,
> > > > + (unsigned long)npriv->rootfh_len);
> > > > + return -EIO;
> > > really EIO?
> > That's a protocol error and -EIO is what is returned in other places for
> > protocol errors, too. Still if you have a better suggestion ...
>
> -EPROTO no?
For the nfs-side EPROTO looks good, but for the caller of the fs
functions EIO seems more sensible because the caller didn't violate any
protocol. For that it's just a "failed to read" thing.
(BTW, I like my bike sheds being blue. :-)
> > > > - ret = rpc_lookup_req(npriv, PROG_NFS, 2);
> > > > + ret = rpc_lookup_req(npriv, PROG_NFS, 3);
> > >
> > > so we loose nfs2?
> > Right. Do you consider it a loss? I don't think it worth to implement
> > both side by side.
>
> I see this as a compatibility issue
Sure it's a compatibility issue. But I guess it won't bite anyone. nfs3
exists since 1995 (the rfc that is). nfsd-v3 support is in Linux 2.4.0
(from 2003) and I bet that any distro-Kernel that has nfsd enabled also
knows about nfs3. So I think it's sane to drop nfs2 support from barebox
which will only bitrot otherwise.
Best regards
Uwe
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
_______________________________________________
barebox mailing list
barebox@xxxxxxxxxxxxxxxxxxx
http://lists.infradead.org/mailman/listinfo/barebox
