> From: Stefano Garzarella <sgarzare@xxxxxxxxxx> > Sent: Thursday, October 28, 2021 3:08 PM > >> >$ vdpa/vdpa dev add mgmtdev vdpasim_net name vdpa0 mac > >> >00:11:22:33:44:55 $ echo 0 > /sys/bus/vdpa/drivers_autoprobe > >> > > >> >And after vdpa device creation, it manually binds to the desired > >> >driver such as, > >> > > >> >$ echo vdpa0 > /sys/bus/vdpa/drivers/virtio_vdpa/bind > >> >Or > >> >$ echo vdpa0 > /sys/bus/vdpa/drivers/vhost_vdpa/bind > >> > >> Cool, I didn't know that. This is very useful, but do you think it > >> might be better to integrate it with the netlink API and specify at > >> creation which bus driver to use? > >I think it is useful; for vduse case we need the ability to say "none" > >as well and when nothing specified it should be default driver. > > Yep, the default can be the actual behaviour. > > > > >More than netlink, I think we need the ability in the core kernel to > >make this choice. > > Okay, but I think we can include that in the vdpa tool. If functionality and interface exists in other part of the it is hard to wrap that in vdpa tool that does the duplicate work. > > >I haven't explored what is already available to make that happen. > > Me too, I only saw the .match() callback of "struct bus_type" that could be used > for this purpose. > > >If/once its available, I am sure it has more users than just vdpa. > > Make sense. I'll spend some time next week. Ok. yeah, may be a desired driver can be stored in the vdpa_device that match() routine can use. And if that driver is not available, it returns EPROBE_DEFER; so whenever such driver is loaded it can be bind. But I think before wrapping something in vdpa, need to find a reason why the current interface doesn't solve the problem and also to figure out plumbing. _______________________________________________ Virtualization mailing list Virtualization@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linuxfoundation.org/mailman/listinfo/virtualization
