On Sat, Jan 14, 2023 at 12:59:04AM +0100, Hans van Kranenburg wrote: > The project plan (that could be drafted on an A4 paper) could look like, > gather around all distro maintainers of Linux distro's that are shipping > Xen, and then search for a 'Project owner', which we totally need to be > someone that is actually employed at a company that actually cares about > getting the results of this.
While Qubes release upgrade would benefit from this feature a bit (but see remark at the end), I'm afraid it isn't high enough on our priority list to dedicate enough time for this... In a long term, I'd rather invest in making hypervisor ABI itself stable, so libxenX.Y would work with Xen X.Y-n too. That's rather far away, but AFAIK it is on Xen upstream roadmap. > Then we go look at the Debian stuff and fix upstream to do the same > thing, also fixing all the init/systemd stuff that got lost along the > way, and then we can push it down to all other distro's as well again. IIUC, since Debian ships wrappers for various Xen tools that choose the right version, just getting native systemd units shouldn't be that hard. But yes, syncing those init scripts back together is substantially more work. > And after all of that is done, there will be a time where we actually > (at Debian) can have a different response to everything init script > related than "sorry, probably won't happen". FWIW, we have a bodge for 922033 as a package that patches some of those init scripts: https://github.com/qubesOS/qubes-vmm-xen-guest (xendriverdomain.service is shipped via another package, for historical reasons). > If you look at the init script stuff in Xen upstream already, it quickly > shows that it's just a total dumpster fire. Someone cobbled up something > in the year 2005, and after that, only changes have been made by people > who actually tried to touch it for a few seconds with a 10-foot pole. systemd units are likely in significantly better shape. They are actually used in production at least by Fedora, Qubes and OpenSUSE, contrary to legacy sysvinit scripts. > So, nobody is really caring about this. There is not an actual person > upstream who is involved into this. As long as that's the case, it's not > a healthy thing for ourselves to start to try fixing all of that from a > downstream POV. > > We're currently doing 'good' with the Debian Xen Team, I think. We can > keep up with security updates, and we're in some sort of OK position to > get the essential stuff into place for Bookworm, but to say it in good > Dutch "Nee, het houdt niet over...". > > Knorrie > > P.S. and if you think "I have no idea what you're rambling about > Knorrie, I have never experienced that problem", well, then thank you > for using Debian ;] > > *) Yeah, this works for PV and PVH, but until the #$^$%& qemu stops > using internal unstable function calls any more so that it doesn't have > to hard depend on libxenmisc4.1X any more, you're still screwed for HVM. > BUT! if you just shut down the domUs nicely and reboot and you have to > go back, then dpkg -i or whatever the previous qemu and you can still > start all domUs again instead of going into full panic mode during the > night. Unfortunately the same caveat applies to libvirt, and while qemu uses only very few functions from the unstable API, with libvirt it's the whole libxl, so it's very far from dropping that pain point... So, if you manage Xen domains via libvirt, not xl directly, you're screwed in PV and PVH case too. -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab
signature.asc
Description: PGP signature
