> From: Jason Wang <jasowang@xxxxxxxxxx> > Sent: Wednesday, June 23, 2021 9:39 AM > > 在 2021/6/22 下午10:03, Parav Pandit 写道: > >> 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. > > > >> 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? > >> > > 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. > > Otherwise we need to implement another bitmask too to tell which fields > from the struct are valid and share with user space. > > 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@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
