Re: [PATCH v3 15/15] Drivers: hv: Add modules to expose /dev/mshv to VMMs running on Hyper-V

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 9/26/2023 1:03 AM, Greg KH wrote:
On Tue, Sep 26, 2023 at 07:00:51AM +0000, Wei Liu wrote:
On Tue, Sep 26, 2023 at 08:31:03AM +0200, Greg KH wrote:
On Tue, Sep 26, 2023 at 05:54:34AM +0000, Wei Liu wrote:
On Tue, Sep 26, 2023 at 06:52:46AM +0200, Greg KH wrote:
On Mon, Sep 25, 2023 at 05:07:24PM -0700, Nuno Das Neves wrote:
On 9/23/2023 12:58 AM, Greg KH wrote:
Also, drivers should never call pr_*() calls, always use the proper
dev_*() calls instead.


We only use struct device in one place in this driver, I think that is the
only place it makes sense to use dev_*() over pr_*() calls.

Then the driver needs to be fixed to use struct device properly so that
you do have access to it when you want to print messages.  That's a
valid reason to pass around your device structure when needed.


What is the tangible benefit of using dev_*() over pr_*()? As I said,
our use of struct device is very limited compared to all the places we
may need to log errors.

pr_*() is used by many, many drivers; it seems to be the norm. We can
certainly add a pr_fmt to improve the logging.

Greg, ACRN and Nitro drivers do not pass around the device structure.
Instead, they rely on a global struct device. We can follow the same.

A single global struct device is wrong, please don't do that.

Don't copy bad design patterns from other drivers, be better :)


What makes it a bad pattern? It seems to be well-established, and is
also used by KVM which this driver is loosely modeled after:
https://elixir.bootlin.com/linux/v6.5.5/source/virt/kvm/kvm_main.c#L5128


If we're working with real devices like network cards or graphics cards
I would agree -- it is easy to imagine that we have several cards of the
same model in the system -- but in real world there won't be two
hypervisor instances running on the same hardware.

We can stash the struct device inside some private data fields, but that
doesn't change the fact that we're still having one instance of the
structure. Is this what you want? Or do you have something else in mind?

You have a real device, it's how userspace interacts with your
subsystem.  Please use that, it is dynamically created and handled and
is the correct representation here.


Are you referring to the struct device we get from calling
misc_register? If not, please be more specific.

How would you suggest we get a reference to that device via e.g. open()
or ioctl() without keeping a global reference to it?


Thanks,
Nuno




[Index of Archives]     [Linux Samsung SoC]     [Linux Rockchip SoC]     [Linux Actions SoC]     [Linux for Synopsys ARC Processors]     [Linux NFS]     [Linux NILFS]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Yosemite News]     [Linux Kernel]     [Linux SCSI]


  Powered by Linux