From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38003) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1c2CtF-0004cW-If for qemu-devel@nongnu.org; Thu, 03 Nov 2016 03:56:50 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1c2CtE-0003HG-N3 for qemu-devel@nongnu.org; Thu, 03 Nov 2016 03:56:49 -0400 From: Markus Armbruster References: <20161102175539.4375-1-mreitz@redhat.com> Date: Thu, 03 Nov 2016 08:56:34 +0100 In-Reply-To: <20161102175539.4375-1-mreitz@redhat.com> (Max Reitz's message of "Wed, 2 Nov 2016 18:55:36 +0100") Message-ID: <87y4113sjx.fsf@dusky.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH for-2.8? 0/3] block/curl: Drop TFTP "support" List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Max Reitz Cc: qemu-block@nongnu.org, Kevin Wolf , Jeff Cody , qemu-devel@nongnu.org Max Reitz writes: > See patch 3 for the reason why we have actually never supported TFTP at > all (except for very small files (i.e. below 256 kB or so)). Care to explain why it works "for very small files" in a bit more detail? PATCH 3 gives a "does not support byte ranges" hint, but to go from there to "very small files", you need to know more about how the block layer works than I can remember right now. > I would consider this series a bug fix because, well, it doesn't really > change any functionality, and the bug is "We don't support TFTP but we > pretend we do". > > > Alternatives to this approach: > > - Deprecate TFTP first. Wait one version, then drop it. > > We could do this, but I personally don't think it's necessary. We have > done this for host_floppy, but in contrast to host_floppy, TFTP really > has never worked. "(except for very small files (i.e. below 256 kB or so)" > Thus, I conclude that nobody is actually using it or > has ever used it for real work. Plausible. > Still, if you think otherwise, we can still do this, of course. > > - Don't remove TFTP altogether, but just emit a run-time error like we > do for HTTP servers that do not support range-based requests. > > Seems dirty and not like the real solution to me. Also, we have > removed other block drivers in the past, so I don't think we should > keep TFTP. Well, the run-time error with HTTP happens when we have a losing server, while with TFTP, no non-losing servers can exist (except for very small files). Anyway, I'm fine with dropping TFTP right away. I'd probably squash the three patches, but that's a matter of taste.