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