On 1/14/22 5:32 PM, Gerd Hoffmann wrote:
Hi,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 [3]. WIP: 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?
Simply for the "potential" backend diversity. I have to admit that I haven't figured out another backend which would be commonly-seen either, which is also one part of the reason why the interfaces are not firming up right now.
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 take care, Gerd
Indeed, the subsystem is an over-abstraction. The forwarding way is much neater, considering how things really work nowadays.
Anyway, thanks for the practical suggestion, it will be revised, along with other designs around the path I'm currently working on.
Regards, Ruien
