On Wed, 05 Aug 2020 12:35:01 +0100
Sean Mooney <smooney(a)redhat.com> 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(a)intel.com 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?
(...)
> Thanks for the explanation, I'm still fuzzy about the
details.
> Anyway, I suggest you to check "devlink dev info" command we have
> implemented for multiple drivers.
is devlink exposed as a filesytem we can read with just open?
openstack will likely try to leverage libvirt to get this info but when we
cant its much simpler to read sysfs then it is to take a a depenency on a commandline
too and have to fork shell to execute it and parse the cli output.
pyroute2 which we use in some openstack poject has basic python binding for devlink but
im not
sure how complete it is as i think its relitivly new addtion. if we need to take a
dependcy
we will but that would be a drawback fo devlink not that that is a large one just
something
to keep in mind.
A devlinkfs, maybe? At least for reading information (IIUC, "devlink
dev info" is only about information retrieval, right?)