qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH for-2.8? 0/3] block/curl: Drop TFTP "support"


From: Markus Armbruster
Subject: Re: [Qemu-devel] [PATCH for-2.8? 0/3] block/curl: Drop TFTP "support"
Date: Thu, 03 Nov 2016 08:56:34 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Max Reitz <address@hidden> 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.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]