On 8/13/20 11:33 AM, Cornelia Huck wrote: > On Fri, 7 Aug 2020 13:59:42 +0200 > Cornelia Huck <cohuck@xxxxxxxxxx> wrote: > >> On Wed, 05 Aug 2020 12:35:01 +0100 >> Sean Mooney <smooney@xxxxxxxxxx> wrote: >> >>> On Wed, 2020-08-05 at 12:53 +0200, Jiri Pirko wrote: >>>> Wed, Aug 05, 2020 at 11:33:38AM CEST, yan.y.zhao@xxxxxxxxx wrote: >> >> (...) >> >>>>> software_version: device driver's version. >>>>> in <major>.<minor>[.bugfix] scheme, where there is no >>>>> compatibility across major versions, minor versions have >>>>> forward compatibility (ex. 1-> 2 is ok, 2 -> 1 is not) and >>>>> bugfix version number indicates some degree of internal >>>>> improvement that is not visible to the user in terms of >>>>> features or compatibility, >>>>> >>>>> vendor specific attributes: each vendor may define different attributes >>>>> device id : device id of a physical devices or mdev's parent pci device. >>>>> it could be equal to pci id for pci devices >>>>> aggregator: used together with mdev_type. e.g. aggregator=2 together >>>>> with i915-GVTg_V5_4 means 2*1/4=1/2 of a gen9 Intel >>>>> graphics device. >>>>> remote_url: for a local NVMe VF, it may be configured with a remote >>>>> url of a remote storage and all data is stored in the >>>>> remote side specified by the remote url. >>>>> ... >>> just a minor not that i find ^ much more simmple to understand then >>> the current proposal with self and compatiable. >>> if i have well defiend attibute that i can parse and understand that allow >>> me to calulate the what is and is not compatible that is likely going to >>> more useful as you wont have to keep maintianing a list of other compatible >>> devices every time a new sku is released. >>> >>> in anycase thank for actully shareing ^ as it make it simpler to reson about what >>> you have previously proposed. >> >> So, what would be the most helpful format? A 'software_version' field >> that follows the conventions outlined above, and other (possibly >> optional) fields that have to match? > > Just to get a different perspective, I've been trying to come up with > what would be useful for a very different kind of device, namely > vfio-ccw. (Adding Eric to cc: for that.) > > software_version makes sense for everybody, so it should be a standard > attribute. > > For the vfio-ccw type, we have only one vendor driver (vfio-ccw_IO). > > Given a subchannel A, we want to make sure that subchannel B has a > reasonable chance of being compatible. I guess that means: > > - same subchannel type (I/O) > - same chpid type (e.g. all FICON; I assume there are no 'mixed' setups > -- Eric?) Correct. > - same number of chpids? Maybe we can live without that and just inject > some machine checks, I don't know. Same chpid numbers is something we > cannot guarantee, especially if we want to migrate cross-CEC (to > another machine.) I think we'd live without it, because I wouldn't expect it to be consistent between systems. > > Other possibly interesting information is not available at the > subchannel level (vfio-ccw is a subchannel driver.) I presume you're alluding to the DASD uid (dasdinfo -x) here? > > So, looking at a concrete subchannel on one of my machines, it would > look something like the following: > > <common> > software_version=1.0.0 > type=vfio-ccw <-- would be vfio-pci on the example above > <vfio-ccw specific> > subchannel_type=0 > <vfio-ccw_IO specific> > chpid_type=0x1a > chpid_mask=0xf0 <-- not sure if needed/wanted > > Does that make sense? >
