From: Jason Wang <jasowang@redhat.com>
Sent: Wednesday, June 23, 2021 9:39 AM

在 2021/6/22 下午10:03, Parav Pandit 写道:

quoted

quoted

Is it better to use a separate enum for net specific attributes?

Yes, because they are only net specific.
I guess it is related to your below question.

quoted

Another question (sorry if it has been asked before). Can we simply
return the config (binary) to the userspace, then usespace can use
the existing uAPI like virtio_net_config plus the feature to explain the

config?

quoted

quoted

We did discuss in v2.
Usually returning the whole blob and parsing is not desired via netlink.
Returning individual fields give the full flexibility to return only the valid

fields.

quoted

Otherwise we need to implement another bitmask too to tell which fields

from the struct are valid and share with user space.

quoted

Returning individual fields is the widely used approach.

The main concerns are:

1) The blob will be self contained if it was passed with the negotiated
features, so we don't need bitmask.

Which fields of the struct are valid is told by additional fields.

2) Using individual fields means it must duplicate the config fields of every
virtio devices

Mostly no. if there are common config fields across two device types, they would be named as
VDPA_ATTR_DEV_CFG_*
Net specific will be,
VDPA_ATTR_DEV_NET_CFG_*
Block specific, will be,
VDPA_ATTR_DEV_BLK_CFG_*

And actually, it's not the binary blob since uapi clearly define the format (e.g
struct virtio_net_config), can we find a way to use that? E.g introduce
device/net specific command and passing the blob with length and
negotiated features.

Length may change in future, mostly expand. And parsing based on length is not such a clean way.
Parsing fields require knowledge of features as well and application needs to make multiple netlink calls to parse the config space.
I prefer to follow rest of the kernel style to return self contained invidividual fields.
_______________________________________________
Virtualization mailing list
Virtualization@lists.linux-foundation.org
https://lists.linuxfoundation.org/mailman/listinfo/virtualization