From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42423) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c80yQ-0000QA-N9 for qemu-devel@nongnu.org; Sat, 19 Nov 2016 03:26:11 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c80yL-0003vG-QM for qemu-devel@nongnu.org; Sat, 19 Nov 2016 03:26:10 -0500 Received: from bart.luffy.cx ([78.47.78.131]:49707) by eggs.gnu.org with esmtps (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1c80yL-0003uY-Gt for qemu-devel@nongnu.org; Sat, 19 Nov 2016 03:26:05 -0500 From: Vincent Bernat References: <20161118175128.17192-1-samuel.thibault@ens-lyon.org> <20161118175128.17192-2-samuel.thibault@ens-lyon.org> <6e88c2ca-d43b-27ab-6acb-fa4c958ca976@redhat.com> Date: Sat, 19 Nov 2016 09:03:08 +0100 In-Reply-To: <6e88c2ca-d43b-27ab-6acb-fa4c958ca976@redhat.com> (Thomas Huth's message of "Sat, 19 Nov 2016 08:32:07 +0100") Message-ID: <87twb3dhhf.fsf@luffy.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [Qemu-devel] [PULL] tftp: fake support for netascii protocol List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Thomas Huth Cc: qemu-devel@nongnu.org, samuel.thibault@ens-lyon.org, Jan Kiszka , Stefan Hajnoczi =E2=9D=A6 19 novembre 2016 08:32 +0100, Thomas Huth =C2= =A0: >> 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. > > That sounds somewhat wrong to me. QEMU now seems to support a transfer > mode that is not really implemented. On the other hand, the current implementation may not RFC compliant as the three modes (netascii, octet, mail) are not supported (but the RFC predates the usage of MAY/SHOULD/MUST, so it's unclear for me). I have tried to add proper support, but this is more invasive as we cannot just seek in the file to get each block. However, this is something that I can do if compliance is important for QEMU. > I think you should at least issue a qemu_log_mask(LOG_UNIMP, "...") > call in that case. I can do that if needed. --=20 10.0 times 0.1 is hardly ever 1.0. - The Elements of Programming Style (Kernighan & Plauger)