Re: [PATCH 0/6] Low speed Hyper-V devices support

[Greg KH]

On Sat, Feb 17, 2024 at 11:51:14PM -0800, Saurabh Singh Sengar wrote:
> On Sun, Feb 18, 2024 at 08:10:36AM +0100, Greg KH wrote:
> > On Sat, Feb 17, 2024 at 10:03:34AM -0800, Saurabh Sengar wrote:
> > > Hyper-V is adding multiple low speed "speciality" synthetic devices.
> > > Instead of writing a new kernel-level VMBus driver for each device,
> > > make the devices accessible to user space through UIO-based
> > > uio_hv_generic driver. Each device can then be supported by a user
> > > space driver. This approach optimizes the development process and
> > > provides flexibility to user space applications to control the key
> > > interactions with the VMBus ring buffer.
> > > 
> > > The new synthetic devices are low speed devices that don't support
> > > VMBus monitor bits, and so they must use vmbus_setevent() to notify
> > > the host of ring buffer updates. These new devices also have smaller
> > > ring buffer sizes which requires to add support for variable ring buffer
> > > sizes.
> > > 
> > > Moreover, this patch series adds a new implementation of the fcopy
> > > application that uses the new UIO driver. The older fcopy driver and
> > > application will be phased out gradually. Development of other similar
> > > userspace drivers is still underway.
> > > 
> > > 
> > > Efforts have been made previously to implement this solution earlier.
> > > Here are the discussions related to those attempts:
> > > https://lore.kernel.org/lkml/1691132996-11706-1-git-send-email-ssengar@xxxxxxxxxxxxxxxxxxx/
> > > https://lore.kernel.org/lkml/1665575806-27990-1-git-send-email-ssengar@xxxxxxxxxxxxxxxxxxx/
> > > https://lore.kernel.org/lkml/1665685754-13971-1-git-send-email-ssengar@xxxxxxxxxxxxxxxxxxx/
> > 
> > So is this a v4 of the patch series?  What has changed from those
> > previous submissions?
> 
> In the most recent attempt we introduced a new driver uio_hv_vmbus_client
> for slow devices, where as in this new approach we are making use of
> existing uio_hv_generic driver.
> 
> We also introduced the function to query ring buffer sizes, this is an
> attempt to address your comment on earlier series to avoid kernel params.
> Comment ref: https://lore.kernel.org/lkml/Y0bipdisMbTNMYOq@xxxxxxxxx/
> 
> We later tried to have ring buffer sizes via sysfs for which we wrote a
> new driver uio_hv_vmbus_client as explained above.
> 
> This is the next approach in an attempt to address all of the concerns
> with all the previous series.

Then you need to say that somewhere, what differs from the previous
submissions and why this is better.  Remember, some of us get 1000+
emails a day to do something with, and trying to remember a review
comment from last week, let alone months ago, is impossible.

Make this easy for us please...

And as this is a "next approach", it should be versioned properly.  What
would you want to see if you had to review this?

thanks,

greg k-h