On 13/11/2020 16:55, Bjoern Doebel wrote: > > On 13.11.20 15:30, Andrew Cooper wrote: >> On 13/11/2020 14:18, Bjoern Doebel wrote: >>> Right now we do not have a mechanism to determine the version of the >>> currently running xenstored at runtime. As xenstored runs throughout >>> the >>> lifetime of a Xen host, this may lead to problems when newer user space >>> builds are staged. Then, the running xenstored will no longer match the >>> version of the installed xenstored. >>> >>> To allow users to always identify the running version of xenstored, add >>> a linker-generated unique build ID to every xenstored build. Add >>> functionality to log this build ID into a file upon service startup. >>> >>> Signed-off-by: Bjoern Doebel <[email protected]> >>> Reviewed-by: Martin Mazein <[email protected]> >>> Reviewed-by: Paul Durrant <[email protected]> >> I understand the problem you're trying to solve, but why is this >> anything more than just enabling build-id's by default across tools/ ? >> >> There are already standard ways of interacting with the build id of >> running executables on the system. I'd strongly discourage doing >> anything custom in xenstored specifically. > May I ask what tooling you would use to interact with a running > process' buildid?
Amongst other things, yes. Although as Juergen points out, we want something which works with stub domains as well, and "normal userspace tools" won't cut it there. I still think a first patch in this series should be to turn build-id's on by default if supported by the toolchain, generally. ~Andrew
