Re: [PATCH v3 2/3] XENVER_build_id: Provide ld-embedded build-ids (v8)

From: Konrad Rzeszutek Wilk <konrad@kernel.org>
To: Jan Beulich <JBeulich@suse.com>
Cc: wei.liu2@citrix.com, ian.campbell@citrix.com,
	andrew.cooper3@citrix.com, ian.jackson@eu.citrix.com,
	mpohlack@amazon.de, xen-devel@lists.xenproject.org,
	dgdegra@tycho.nsa.gov
Subject: Re: [PATCH v3 2/3] XENVER_build_id: Provide ld-embedded build-ids (v8)
Date: Wed, 13 Jan 2016 21:02:30 -0500	[thread overview]
Message-ID: <20160114020226.GA8254@x230.dumpdata.com> (raw)
In-Reply-To: <56953F2D02000078000C60DB@prv-mh.provo.novell.com>

> > Or are you suggesting that perhaps the kernel should at boot time
> > print the build-id (like it does the changset)?
> 
> Perhaps, albeit to me that's a bit orthogonal to being able to find out
> the build ID for a given binary.

I can make some magic objdump + awk to extract the buildid from
the hypervisor and deposit as a text file in /usr/../xen/debug?
Similar to how xen-syms is copied there?

Would that work?

But I am a bit lost of what your use-case is?

The third patch implements 'xl info' to display it.

> 
> >> > +        if ( rc )
> >> > +            return rc;
> >> > +
> >> > +        if ( guest_handle_is_null(arg) )
> >> > +            return sz;
> >> > +
> >> > +        if ( sz > build_id.len )
> >> > +            return -ENOBUFS;
> >> 
> >> And how will the caller know how much is needed?
> > 
> > Duh. I shall update the build_id.len with the appropiate value.
> 
> Ah, actually I now see you have Andrew's beloved NULL handle
> check up a few lines - that may suffice. Albeit I'm not generally in
> favor of this model; I prefer a first attempt to succeed if possible,
> and a second one only to be needed if the caller estimated size in
> fact didn't suffice (and then no 3rd one being necessary in order
> to obtain the needed size).

The code I wrote (libxl) tries with a large buffer (1020 bytes)
and if that didn't work just reports the error.

I shall change the code to follow your steps.