On Mon, 2025-09-15 at 23:37 +0200, Filip Hejsek wrote: > Hi, > > On Mon, 2025-09-15 at 18:44 +0200, Maximilian Immanuel Brandtner > wrote: > > [...] > > As I already mentioned in the QEMU discussion, I proposed the fix, > > because I was working on a similar implementation to bring resizing > > to > > QEMU. > > I couldn't find any mention of your implementation on the QEMU ML. > > > Unfortunately, the patch-set was stuck in limbo for a while and > > now that someone else has picked up the slack, I've descided that > > it's > > better to contribute to the patch-set that is upstream instead of > > sending a competing patch-set that does the same thing. > > Would it be OK for me to take a look at your WIP patches? I would > like > to see if you did anything differently. >
For the stuff I can get clearance for anyways. The tl:dr of what's different about my patch-set is as follows: - introduce a new IOResizeHandler instead of using a chr backend event - dynamically add a QOM-property to every character device that supports resizing (instead of the qmp-command that you have implemented) - guest chardev implementations I also used a g_unix_signal_source instead of a signal notifier and it worked during testing, but I prefer your solution > Also, you mentioned before that you were also working on patches for > Libvirt. These will still be useful, because I won't be implementing > that part. > I haven't properly implemented it for libvirt either. The libvirt patch -set would have to be somewhat sizeable as well as virStream currently doesn't implement a handle to perform hypervisor specific calls (which a resize QMP call would be). Accordingly, the virStream implementation would have to be changed on a deeper level which is why I just didn't come around to it (I would also need to familiarize myself first with libvirt more which I haven't done yet). > > [...] > > I don't really care if this discrepancy is fixed one way or the > > other, > > but it should most definitely be fixed. > > I'm of the same opinion, but if it is fixed on the kernel side, then > (assuming no device implementation with the wrong order exists) I > think > maybe the fix should be backported to all widely used kernels. It > seems > that the patch hasn't been backported to the longterm kernels [1], > which I think Debian kernels are based on. > > [1]: > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/log/drivers/char/virtio_console.c?h=v6.12.47 > Then I guess the patch-set should be backported > > Kind regards, > > Max Brandtner > > Regards, > Filip Hejsek
