Re: [Qemu-devel] [v2] tftp: fake support for netascii protocol

[Stefan Hajnoczi]

On Mon, Nov 21, 2016 at 04:05:41PM +0100, Samuel Thibault wrote:
> Stefan Hajnoczi, on Mon 21 Nov 2016 14:46:16 +0000, wrote:
> > On Sun, Nov 20, 2016 at 09:41:36AM +0100, Vincent Bernat wrote:
> > > From: Vincent Bernat <address@hidden>
> > > 
> > > Some network equipments are requesting a file using the netascii
> > > protocol and this is not configurable. Currently, qemu's tftpd only
> > > supports the octet protocol. This commit makes it accept the netascii
> > > protocol as well but do not perform the requested transformation (LF ->
> > > CR,LF) as it would be far more complex. The current implementation is
> > > good enough. A user has always the choice to preencode the served file
> > > correctly.
> > > 
> > > Signed-off-by: Vincent Bernat <address@hidden>
> > > ---
> > >  slirp/tftp.c | 11 ++++++++---
> > >  1 file changed, 8 insertions(+), 3 deletions(-)
> > > 
> > > diff --git a/slirp/tftp.c b/slirp/tftp.c
> > > index c1859066ccb2..6907d5b92074 100644
> > > --- a/slirp/tftp.c
> > > +++ b/slirp/tftp.c
> > > @@ -26,6 +26,7 @@
> > >  #include "slirp.h"
> > >  #include "qemu-common.h"
> > >  #include "qemu/cutils.h"
> > > +#include "qemu/log.h"
> > >  
> > >  static inline int tftp_session_in_use(struct tftp_session *spt)
> > >  {
> > > @@ -326,13 +327,17 @@ static void tftp_handle_rrq(Slirp *slirp, struct 
> > > sockaddr_storage *srcsas,
> > >      return;
> > >    }
> > >  
> > > -  if (strcasecmp(&tp->x.tp_buf[k], "octet") != 0) {
> > > +  if (strcasecmp(&tp->x.tp_buf[k], "octet") == 0) {
> > > +      k += 6;
> > > +  } else if (strcasecmp(&tp->x.tp_buf[k], "netascii") == 0) {
> > > +      qemu_log_mask(LOG_UNIMP, "tftp: netascii protocol not implemented, 
> > > "
> > > +                    "no CR-LF conversion\n");
> > > +      k += 9;
> > > +  } else {
> > 
> > This is an RFC violation.  I don't think it's suitable for upstream QEMU.
> > 
> > The commit description says it would be "far more complex" to implement
> > netascii.  Is the LF -> CR LF and CR -> CR NUL transformation so hard?
> 
> I guess the question is that while the patch above could be accepted for
> the upcoming 2.8 (I don't see it breaking existing systems), a patch
> that would implement the transformation would be a lot more involved,
> and really not suitable for 2.8.

This pull request cannot be accepted for QEMU 2.8 because it is not a
bug fix.  QEMU is in hard feature freeze (until mid-December):
http://qemu-project.org/Planning/HardFeatureFreeze
http://qemu-project.org/Planning/2.8

If you decide to implement netascii in the future, please update the
documentation in qemu-options.hx:

  The TFTP client on the guest must be configured in binary mode (use
  the command @code{bin} of the Unix TFTP client).

Thanks,
Stefan

signature.asc
Description: PGP signature