All of lore.kernel.org
 help / color / mirror / Atom feed
From: Markus Armbruster <armbru@redhat.com>
To: Max Reitz <mreitz@redhat.com>
Cc: qemu-block@nongnu.org, Kevin Wolf <kwolf@redhat.com>,
	Jeff Cody <jcody@redhat.com>,
	qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] [PATCH for-2.8? 0/3] block/curl: Drop TFTP "support"
Date: Thu, 03 Nov 2016 08:56:34 +0100	[thread overview]
Message-ID: <87y4113sjx.fsf@dusky.pond.sub.org> (raw)
In-Reply-To: <20161102175539.4375-1-mreitz@redhat.com> (Max Reitz's message of "Wed, 2 Nov 2016 18:55:36 +0100")

Max Reitz <mreitz@redhat.com> 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.

  parent reply	other threads:[~2016-11-03  7:56 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-11-02 17:55 [Qemu-devel] [PATCH for-2.8? 0/3] block/curl: Drop TFTP "support" Max Reitz
2016-11-02 17:55 ` [Qemu-devel] [PATCH for-2.8? 1/3] qemu-options: Drop mentions of curl's TFTP support Max Reitz
2016-11-02 18:20   ` Jeff Cody
2016-11-02 17:55 ` [Qemu-devel] [PATCH for-2.8? 2/3] qapi: Drop curl's TFTP protocol Max Reitz
2016-11-02 18:22   ` Jeff Cody
2016-11-02 17:55 ` [Qemu-devel] [PATCH for-2.8? 3/3] block/curl: Drop TFTP "support" Max Reitz
2016-11-02 18:22   ` Jeff Cody
2016-11-02 18:20 ` [Qemu-devel] [PATCH for-2.8? 0/3] " Jeff Cody
2016-11-03  7:56 ` Markus Armbruster [this message]
2016-11-04 16:53   ` Max Reitz
2016-11-07  8:20     ` Markus Armbruster
2016-11-07 15:42       ` Max Reitz
2016-11-08  7:14         ` Markus Armbruster
2016-11-09 19:15           ` Jeff Cody
2016-11-11 19:46             ` Max Reitz
2016-11-14 18:54               ` Jeff Cody
2016-11-03  9:42 ` Kevin Wolf
2016-11-07 12:57 ` [Qemu-devel] [Qemu-block] " Stefan Hajnoczi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87y4113sjx.fsf@dusky.pond.sub.org \
    --to=armbru@redhat.com \
    --cc=jcody@redhat.com \
    --cc=kwolf@redhat.com \
    --cc=mreitz@redhat.com \
    --cc=qemu-block@nongnu.org \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.