From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42722) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c8qAK-0001Ga-BH for qemu-devel@nongnu.org; Mon, 21 Nov 2016 10:05:56 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c8qAD-00041x-T9 for qemu-devel@nongnu.org; Mon, 21 Nov 2016 10:05:52 -0500 Received: from mail2-relais-roc.national.inria.fr ([192.134.164.83]:45252) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c8qAD-00041A-Ht for qemu-devel@nongnu.org; Mon, 21 Nov 2016 10:05:45 -0500 Date: Mon, 21 Nov 2016 16:05:41 +0100 From: Samuel Thibault Message-ID: <20161121150541.GA728@var.bordeaux.inria.fr> References: <20161119223003.GD10378@var.home> <20161120084136.721-1-Vincent.Bernat@exoscale.ch> <20161121144616.GG15478@stefanha-x1.localdomain> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20161121144616.GG15478@stefanha-x1.localdomain> Subject: Re: [Qemu-devel] [v2] tftp: fake support for netascii protocol List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Stefan Hajnoczi Cc: Vincent Bernat , Thomas Huth , qemu-devel@nongnu.org, Jan Kiszka , Vincent Bernat , "H. Peter Anvin" 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 > > > > 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 > > --- > > 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. Samuel