[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <ca016eca-1ee7-2d0f-c2ec-3ef147b6216a@linux.ibm.com>
Date: Wed, 26 Aug 2020 10:49:47 -0400
From: Tony Krowiak <akrowiak@...ux.ibm.com>
To: Cornelia Huck <cohuck@...hat.com>
Cc: linux-s390@...r.kernel.org, linux-kernel@...r.kernel.org,
kvm@...r.kernel.org, freude@...ux.ibm.com, borntraeger@...ibm.com,
mjrosato@...ux.ibm.com, pasic@...ux.ibm.com,
alex.williamson@...hat.com, kwankhede@...dia.com,
fiuczy@...ux.ibm.com, frankja@...ux.ibm.com, david@...hat.com,
imbrenda@...ux.ibm.com, hca@...ux.ibm.com, gor@...ux.ibm.com
Subject: Re: [PATCH v10 01/16] s390/vfio-ap: add version vfio_ap module
On 8/25/20 6:04 AM, Cornelia Huck wrote:
> On Fri, 21 Aug 2020 15:56:01 -0400
> Tony Krowiak <akrowiak@...ux.ibm.com> wrote:
>
>> Let's set a version for the vfio_ap module so that automated regression
>> tests can determine whether dynamic configuration tests can be run or
>> not.
>>
>> Signed-off-by: Tony Krowiak <akrowiak@...ux.ibm.com>
>> ---
>> drivers/s390/crypto/vfio_ap_drv.c | 2 ++
>> 1 file changed, 2 insertions(+)
>>
>> diff --git a/drivers/s390/crypto/vfio_ap_drv.c b/drivers/s390/crypto/vfio_ap_drv.c
>> index be2520cc010b..f4ceb380dd61 100644
>> --- a/drivers/s390/crypto/vfio_ap_drv.c
>> +++ b/drivers/s390/crypto/vfio_ap_drv.c
>> @@ -17,10 +17,12 @@
>>
>> #define VFIO_AP_ROOT_NAME "vfio_ap"
>> #define VFIO_AP_DEV_NAME "matrix"
>> +#define VFIO_AP_MODULE_VERSION "1.2.0"
>>
>> MODULE_AUTHOR("IBM Corporation");
>> MODULE_DESCRIPTION("VFIO AP device driver, Copyright IBM Corp. 2018");
>> MODULE_LICENSE("GPL v2");
>> +MODULE_VERSION(VFIO_AP_MODULE_VERSION);
>>
>> static struct ap_driver vfio_ap_drv;
>>
> Setting a version manually has some drawbacks:
> - tools wanting to check for capabilities need to keep track which
> versions support which features
> - you need to remember to actually bump the version when adding a new,
> visible feature
> (- selective downstream backports may get into a pickle, but that's
> arguably not your problem)
>
> Is there no way for a tool to figure out whether this is supported?
> E.g., via existence of a sysfs file, or via a known error that will
> occur. If not, it's maybe better to expose known capabilities via a
> generic interface.
This patch series introduces a new mediated device sysfs attribute,
guest_matrix, so the automated tests could check for the existence
of that interface. The problem I have with that is it will work for
this version of the vfio_ap device driver - which may be all that is
ever needed - but does not account for future enhancements
which may need to be detected by tooling or automated tests.
It seems to me that regardless of how a tool detects whether
a feature is supported or not, it will have to keep track of that
somehow.
Can you provide more details about this generic interface of
which you speak?
>
Powered by blists - more mailing lists