[libvirt] [PATCH v1 11/31] conf: Format and parse NVMe type disk

[Michal Privoznik]

On 7/16/19 2:38 PM, Peter Krempa wrote:
> On Thu, Jul 11, 2019 at 18:16:58 +0200, Peter Krempa wrote:
>> On Thu, Jul 11, 2019 at 18:12:16 +0200, Michal Privoznik wrote:
>>> On 7/11/19 6:05 PM, Peter Krempa wrote:
>>>> On Thu, Jul 11, 2019 at 17:53:58 +0200, Michal Privoznik wrote:
>>>>> To simplify implementation, some restrictions are added. For
>>>>> instance, an NVMe disk can't go to any bus but virtio and has to
>>>>> be type of 'disk' and can't have startupPolicy set.
>>>>>
>>>>> Signed-off-by: Michal Privoznik <mprivozn at redhat.com>
>>>>> ---
> 
> [...]
> 
>> Yes it certainly will be possible with blockdev. Also you have such a
>> file in the backing chain which gets detected from the file metadata on
>> the disk, so such a check will probably need to be duplicated also when
>> starting the VM (the validate callback function may be better match).
>>
>>>
>>>>
>>>> Also this seems all to belong to the qemu specific post parse callback.
>>>
>>> Possibly. But since other drivers would still use virNVMeDevice module I'm
>>> adding later in this series, and since the module is build on these
>>> assumptions I figured the best place to check for them is in driver agnostic
>>> callback.
>>
>> Fair enough.
> 
> Thinking about this a bit more, if there will be a separate module for
> this, that module should expose the validator. 

Well, the module sees virNVMeDevice struct and not virDomainDiskDef 
(these are two different structures). And since we do not want code from 
src/util/ include anything in src/conf/ I'm not quite sure how to access 
virDomainDiskDef from src/util/virnvme.c.

> Also I'm not persuaded
> about the universality of this code at all thus I doubt that it will be
> reused in other hypervisors as it requires a userspace driver for NVMe
> in the hypervisor, which is a pretty niche configuraion/use case.
> 

Well, nearly everything that we work on is qemu specific, because quite 
frankly, we only touch other drivers when an internal API is changed and 
a codebase wide adoption is needed.

Michal