From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH v3 2/3] XENVER_build_id: Provide ld-embedded build-ids (v8) Date: Wed, 13 Jan 2016 21:02:30 -0500 Message-ID: <20160114020226.GA8254@x230.dumpdata.com> References: <1452219920-14043-1-git-send-email-konrad.wilk@oracle.com> <1452219920-14043-3-git-send-email-konrad.wilk@oracle.com> <5695370702000078000C6047@prv-mh.provo.novell.com> <20160112164301.GC17685@char.us.oracle.com> <56953F2D02000078000C60DB@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta4.messagelabs.com ([85.158.143.247]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1aJXFE-0002nB-0l for xen-devel@lists.xenproject.org; Thu, 14 Jan 2016 02:02:36 +0000 Received: by mail-qg0-f65.google.com with SMTP id o11so43704548qge.0 for ; Wed, 13 Jan 2016 18:02:34 -0800 (PST) Content-Disposition: inline In-Reply-To: <56953F2D02000078000C60DB@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich 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 List-Id: xen-devel@lists.xenproject.org > > 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.