On Mon, Feb 20, 2017 at 3:02 AM, Stefan Hajnoczi <stefa...@gmail.com> wrote: > On Sat, Feb 18, 2017 at 12:30:31AM +0000, Ketan Nilangekar wrote: >> On 2/17/17, 1:42 PM, "Jeff Cody" <jc...@redhat.com> wrote: >> >> On Thu, Feb 16, 2017 at 02:24:19PM -0800, ashish mittal wrote: >> > Hi, >> > >> > I am getting the following error with checkpatch.pl >> > >> > ERROR: externs should be avoided in .c files >> > #78: FILE: block/vxhs.c:28: >> > +QemuUUID qemu_uuid __attribute__ ((weak)); >> > >> > Is there any way to get around this, or does it mean that I would have >> > to add a vxhs.h just for this one entry? >> > >> >> I remain skeptical on the use of the qemu_uuid as a way to select the TLS >> cert. >> >> [ketan] >> Is there another identity that can be used for uniquely identifying >> instances? >> The requirement was to enforce vdisk access to owner instances. > > The qemu_uuid weak attribute looks suspect. What is going to provide a > strong qemu_uuid symbol? > > Why aren't configuration parameters like the UUID coming from the QEMU > command-line? > > Stefan
UUID will in fact come from the QEMU command line. VxHS is not doing anything special here. It will just use the value already available to qemu-kvm process. QemuUUID qemu_uuid; bool qemu_uuid_set; Both the above are defined in vl.c. vl.c will provide the strong symbol when available. There are certain binaries that do not get linked with vl.c (e.g. qemu-img). The weak symbol will come into affect for such binaries, and in this case, the default VXHS UUID will get picked up. I had, in a previous email, explained how we plan to use the default UUID. In the regular case, the VxHS controller will not allow access to the default UUID (non qemu-kvm) binaries, but it may choose to grant temporary access to specific vdisks for these binaries depending on the workflow. Regards, Ashish
