On 19/01/2023 6:20 am, Juergen Gross wrote: > On 17.01.23 14:53, Andrew Cooper wrote: >> This is the tools side of the Xen series posted previously. >> >> With this, a Xen built with long strings can be retrieved: >> >> # xl info >> ... >> xen_version : 4.18-unstable+REALLY LONG EXTRAVERSION >> xen_changeset : Tue Jan 3 19:27:17 2023 >> git:52d2da6c0544+REALLY SUPER DUPER EXTRA MEGA LONG CHANGESET >> ... >> >> >> Andrew Cooper (6): >> tools/libxc: Move xc_version() out of xc_private.c into its own file >> tools: Introduce a non-truncating xc_xenver_extraversion() >> tools: Introduce a non-truncating xc_xenver_capabilities() >> tools: Introduce a non-truncating xc_xenver_changeset() >> tools: Introduce a non-truncating xc_xenver_cmdline() >> tools: Introduce a xc_xenver_buildid() wrapper >> >> tools/include/xenctrl.h | 10 ++ >> tools/libs/ctrl/Makefile.common | 1 + >> tools/libs/ctrl/xc_private.c | 66 ------------ >> tools/libs/ctrl/xc_private.h | 7 -- >> tools/libs/ctrl/xc_version.c | 206 >> ++++++++++++++++++++++++++++++++++++ >> tools/libs/light/libxl.c | 61 +---------- >> tools/ocaml/libs/xc/xenctrl_stubs.c | 45 +++++--- >> 7 files changed, 250 insertions(+), 146 deletions(-) >> create mode 100644 tools/libs/ctrl/xc_version.c >> > > Hmm, I'm not completely opposed to this, but do we really need all that > additional code? > > Apart from the build-id all the information is easily available via hypfs.
capabilitiles at the very least isn't there. Not that I'm particularly complaining - its not an interface we want to encourage. > And the build-id can be easily added to hypfs. Hypfs is optional, and you will find firm resistance to making it mandatory for this. Also, having looked at how hypfs_string_set_reference() works, it's not correct with livepatching (nothing updates size). I suspect this only impacts the livepatching "unit" tests which nothing runs (hence why livepatching is *still* broken on 4.15 and later). ~Andrew
