On 6/28/19 1:32 AM, Martin Kletzander wrote:
> Rich still has the idea of adding a 'qemu-nbd --list'
counterpart, so
> defining a constant for the "base:" and "qemu:" namespaces makes
sense
> for that even if we can't use it now. Hmm - your patch defines
> LIBNBD_NAMESPACE_BASE to "base", but in practice we'd want to pass
> "base:" when querying which contexts are available in that namespace.
>
That is on the protocol, but the API does not need to take the ':*' suffix.
Also it is costless to do LIBNBD_NAMESPACE_BASE ":" in the C code.
With my patch, it is currently "base:" in the header (and in the other
language bindings). I suggest that until we actually have an API for
doing listings, it doesn't really matter, we can change it to drop the
trailing ':' at that time if it proves easier to force clients to do the
string constant concatenation for using the new API at that time.
>
> I'd love to have LIBNBD_CONTEXT_QEMU_DIRTY_BITMAP(foo) produce the
> string "qemu:dirty-bitmap:foo". I'm not sure how to wire that in on
top
> of your patches, so it doesn't have to happen today, but it's food for
> thought.
>
You mean, for example:
#define LIBNBD_CONTEXT_QEMU_DIRTY_BITMAP(foo) "qemu:dirty-bitmap:" #foo
I guess it depends on whether call-sites will look like
LIBNBD_CONTEXT_QEMU_DIRTY_BITMAP("foo")
(performing constant string concatenation)
vs.
LIBNBD_CONTEXT_QEMU_DIRTY_BITMAP(foo)
(performing runtime dynamic computation)
so the macro may have to call out to a function and reserve thread-local
storage. It may be another thing where we tweak things based on what's
easiest to implement and easiest for clients to consume.
--
Eric Blake, Principal Software Engineer
Red Hat, Inc. +1-919-301-3226
Virtualization:
qemu.org |
libvirt.org