Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20;
Date:   Sat, 12 Aug 2023 13:14:50 +0200
From:   Greg KH <gregkh@linuxfoundation.org>
To:     Saurabh Sengar <ssengar@linux.microsoft.com>
Cc:     kys@microsoft.com, haiyangz@microsoft.com, wei.liu@kernel.org,
        decui@microsoft.com, mikelley@microsoft.com, corbet@lwn.net,
        linux-kernel@vger.kernel.org, linux-hyperv@vger.kernel.org,
        linux-doc@vger.kernel.org
Subject: Re: [PATCH v4 0/3] UIO driver for low speed Hyper-V devices
Message-ID: <2023081215-canine-fragile-0a69@gregkh>
References: <1691132996-11706-1-git-send-email-ssengar@linux.microsoft.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <1691132996-11706-1-git-send-email-ssengar@linux.microsoft.com>
Precedence: bulk

On Fri, Aug 04, 2023 at 12:09:53AM -0700, 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 a UIO-based
> hv_vmbus_client 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.

Why is it faster to write userspace drivers here?  Where are those new
drivers, and why can't they be proper kernel drivers?  Are all hyper-v
drivers going to move to userspace now?

> 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. The new driver provides this
> functionality along with a configurable ring buffer size.
> 
> Moreover, this series of patches incorporates an update to the fcopy
> application, enabling it to seamlessly utilize the new interface. The
> older fcopy driver and application will be phased out gradually.
> Development of other similar userspace drivers is still underway.
> 
> 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.

You are adding a new user api with the "ring buffer" size api, which is
odd for normal UIO drivers as that's not something that UIO was designed
for.

Why not just make you own generic type uiofs type kernel api if you
really want to do all of this type of thing in userspace instead of in
the kernel?

And finally, if this is going to replace the fcopy driver, then it
should be part of this series as well, removing it to show that you
really mean it when you say it will be deleted, otherwise we all know
that will never happen.

thanks,

greg k-h