[virt-tools-list] [vhostmd PATCH 1/2] Remove libserialclient

[Trapp, Michael]

On 11.12.18, 00:41, "Jim Fehlig" <jfehlig at suse.com> wrote:

    On 12/7/18 11:12 AM, Michael Trapp wrote:
    > There is no need to keep the dump_virtio code in a separate library.
    > Revert libserialclient changes and move the code to libmetrics.
    > 
    > ---
    > 
    > vm-dump-metrics tries to access the metrics disk without a check of the
    > transport methods because the access is located in the libmetrics
    > constructor this can't be changed in vm-dump-metrics.
    
    Yeah, it is tough to change the constructor without changing the library 
    behavior in some small way.
    
    > 
    > libmetrics.c:
    > void __attribute__ ((constructor)) libmetrics_init(void)
    >      ...
    >      if (read_mdisk(mdisk) != 0) {
    >          libmsg("%s(): Unable to read metrics disk\n", __func__);
    > 
    > Whith virtio transport we can't expect a metrics disk and should avoid the
    > error. One option is to remove read_mdisk() from the constructor, initialize
    > mdisk->sum and rely on the read_mdisk() call in read_mdisk_sum().
    
    I never liked the idea of this library and as I recall protested its addition to 
    vhostmd many, many years ago :-). I preferred a simple app (aka vm-dump-metrics) 
    that would simply dump an XML doc of metrics and let the consumer do with it as 
    they please. Do you use the library, or only vm-dump-metrics?

We don't use the library, vm-dump-metrics is sufficient for our use case and
in addition, with vm-dump-metrics we don't care about changes like a new transport method
    
    > This should be discussed and fixed in another patch.
    
    While we're on the topic, I'll discuss it briefly here, but yes needs to be 
    fixed in a separate patch.
    
    I can think of two options for a fix. Option 1, as you suggest, is to remove 
    read_mdisk() from the constructor. IMO, mdisk->sum should be left at 0 as 
    initialized by mdisk_alloc(). We'd need to fixup dump_metrics() to handle that, 
    similar to get_metrics().
    
    Option 2 is adjust the constructor to try populating the metric_disk structure 
    with read_mdisk() first, then with virtio, and only fail if both are 
    unavailable. One upshot of this approach is that the get*_metric APIs would work 
    with virtio by adjusting get_metrics() to handle disk or virtio transport. One 
    downside of this approach is abusing the poorly named "metric_disk" structure. 
    I.e. we'd be populating the structure from virtio instead of a disk. In 
    hindsight "metric_source" or "metric_block" or "metric_packet" or about anything 
    else would have been a better name than "metric_disk" :-).
    
    I tend to prefer option 2 since the get*_metric APIs would work with virtio 
    transport. Do you have a preference, or alternative option?

Option 2 would also provide virtio support in libmetrics but from my perspective there
is no need to have libmetrics available with the vhostmd package.
If it's an option to deprecate libmetrics, I would vote for option 1 and in a next step the
mdisk access could be replaced with a simple dump of the content of the block device.

Regards
Michael