Re: [PATCH v5 0/2] UIO support for dfl devices

[Xu Yilun <yilun.xu@intel.com>]

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