[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] Re: [Xen-devel] [PATCH v3 2/3] XENVER_build_id: Provide ld-embedded build-ids (v8)
Konrad Rzeszutek Wilk writes ("[PATCH v3 2/3] XENVER_build_id: Provide ld-embedded build-ids (v8)"): > The mechanism to get this is via the XENVER hypercall and > we add a new sub-command to retrieve the binary build-id > called XENVER_build_id. The sub-hypercall parameter > allows an arbitrary size (the buffer and len is provided > to the hypervisor). A NULL parameter will probe the hypervisor > for the length of the build-id. > > One can also retrieve the value of the build-id by doing > 'readelf -h xen-syms'. > > For EFI builds we re-use the same build-id that the xen-syms > was built with. > > Note that there are no changes to the XSM files (dummy.c > and hooks.c) as the privileged subops fall in the default case. > > The version of ld that first implemented --build-id is v2.18. > Hence we check for that or later version - if older version > found we do not build the hypervisor with the build-id > (and the return code is -ENODATA for that case). I think this commit message is missing some important explanation for poor ignorant souls like me. Something like: It is possible to have ld record an arbitrary identifier in an ELF, which can then be read out with `readelf'. We also want to provide a way for guests to retrieve the same identifier. [ xxx do we? Maybe hosting providers would want to hide which of their hosts had been updated ] We construct the build-id out of [ ???? ] There is ???? no impact on users who want reproducible builds [or] ??? users who want reproducible builds are expected to use the facilities documented in ??? comments in Config.mk [or something] Ian. _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
Lists.xenproject.org is hosted with RackSpace, monitoring our |