On Sun, Jan 10, 2021 at 11:58:44AM -0800, Moritz Fischer wrote: > Hi Xu, > > On Sat, Jan 02, 2021 at 11:13:00AM +0800, Xu Yilun wrote: > > This patchset supports some dfl device drivers written in userspace. > > > > In the patchset v1, the "driver_override" interface should be used to bind > > the DFL UIO driver to DFL devices. But there is concern that the > > "driver_override" interface is not OK itself. > > > > In v2, we use a new matching algorithem. The "driver_override" interface > > is abandoned, the DFL UIO driver matches any DFL device which could not be > > handled by other DFL drivers. So the DFL UIO driver could be used for new > > DFL devices which are not supported by kernel. The concern is the UIO may > > not be suitable as a default/generic driver for all dfl features, such as > > features with multiple interrupts. > > > > In v4, we specify each matching device in the id_table of the UIO driver, > > just the same as other dfl drivers do. Now the UIO driver supports Ether > > Group feature. To support more DFL features, their feature ids should be > > added to the driver's id_table. > > I think this is what you want, yes. Instead of doing a driver override > or such, add devices that should always be bound to UIO to a device id > table. For those you temporarily want to bind, make sure you can unbind > them and use 'new_id' or 'bind' in sysfs, similar to what sysfs does. "new_id" is not generic to all bus drivers, we need to add the attr in dfl bus driver like pci do, actually I think quite similar to "driver_override", How do you think? I'm glad we restarted the discussion for the temporary binding of UIO driver. Thanks, Yilun
