From: Gerd Hoffmann <email@example.com>
To: Ruien Zhang <firstname.lastname@example.org>
Cc: email@example.com, firstname.lastname@example.org,
Subject: Re: [PATCH 0/2] Introduce printer subsystem and USB printer device
Date: Fri, 14 Jan 2022 10:32:16 +0100 [thread overview]
Message-ID: <email@example.com> (raw)
> This patchset introduces:
> 1) Skeleton of QEMU printer subsystem with a dummy builtin driver.
> 2) USB printer device emulation, with definitions in the extension of IPP-over-
> USB .
> 1) QEMU printer subsystem interfaces, which will be finalized with a concrete
> backend driver.
> 2) IPP-over-USB implementation.
Hmm, I'm wondering what uses cases you have in mind and whenever
it makes sense to introduce a printer subsystem?
Having an ipp-over-usb device looks useful, but the only use case I can
see is to allow guests access a network printer. I can't see the
benefits of a printer subsystem, especially in a world where non-ipp
printers are going extinct. We would most likely have just a single
kind of printer backend, where the only job qemu will have is to
forwarding requests and replies, maybe with some http header rewriting.
Likewise usb would be the one and only device (parallel ports are long
gone in printers). So the indirection added by a printer subsystem
doesn't buy us anything because we just don't need that flexibility.
I'd suggest to pass the url directly to the device instead:
qemu -device usb-ipp-printer,url=ipp://hostname/ipp/printer
next prev parent reply other threads:[~2022-01-14 9:33 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-13 11:56 [PATCH 0/2] Introduce printer subsystem and USB printer device Ruien Zhang
2022-01-13 11:56 ` [PATCH 1/2] printer: Introduce printer subsystem Ruien Zhang
2022-01-13 11:56 ` [PATCH 2/2] usb-printer: Introduce USB printer class Ruien Zhang
2022-01-14 9:32 ` Gerd Hoffmann [this message]
2022-01-14 13:38 ` [PATCH 0/2] Introduce printer subsystem and USB printer device Ruien Zhang
2022-01-15 15:31 ` Ruien Zhang
2022-01-17 7:17 ` Gerd Hoffmann
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:
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
* 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.