Re: [PATCH 03/19] drivers/hv: minimal mshv module (/dev/mshv/)

[Nuno Das Neves]

On 6/2/2021 6:28 PM, Sunil Muthuswamy wrote:
>> diff --git a/drivers/hv/Kconfig b/drivers/hv/Kconfig
>> index 66c794d92391..d618b1fab2bb 100644
>> --- a/drivers/hv/Kconfig
>> +++ b/drivers/hv/Kconfig
>> @@ -27,4 +27,22 @@ config HYPERV_BALLOON
>>  	help
>>  	  Select this option to enable Hyper-V Balloon driver.
>>
>> +config HYPERV_ROOT_API
> 
> A more suitable place to put this would be under the "VIRTUALIZATION"
> config menu option, where we have the "KVM" option today.
> 

Is Xen also under "VIRTUALIZATION"?

>> +	tristate "Microsoft Hypervisor root partition interfaces: /dev/mshv"
>> +	depends on HYPERV
>> +	help
>> +	  Provides access to interfaces for managing guest virtual machines
>> +	  running under the Microsoft Hypervisor.
> 
> These are technically not "root" interfaces. As you say it too, these are
> interfaces to manage guest VMs. Calling it "HYPERV_ROOT_API" would
> be confusing. Something along the lines of "HYPERV_VMM_API" or
> "HYPERV_VM_API" seems more appropriate to me.
> 

Good point - HYPERV_VMM_API might be better.

>> new file mode 100644
>> index 000000000000..c68cc84fb983
>> --- /dev/null
>> +++ b/drivers/hv/mshv_main.c
> Why not in /virt/hv or something under /virt?
> 

We decided that all the non arch-specific hyperv code should live in drivers/hv.

>> +static int mshv_dev_open(struct inode *inode, struct file *filp);
>> +static int mshv_dev_release(struct inode *inode, struct file *filp);
>> +static long mshv_dev_ioctl(struct file *filp, unsigned int ioctl, unsigned long arg);
> 
> Do we need to have both 'mshv' & 'dev' in the name? How about just
> calling these 'mshv_xyz'? Like you have for init/exit.
> 

I wanted a distinction between mshv_* the module, and mshv_dev_* the root device of the module,
but I guess it's effectively the same thing.

>> +
>> +static struct miscdevice mshv_dev = {
>> +	.minor = MISC_DYNAMIC_MINOR,
>> +	.name = "mshv",
>> +	.fops = &mshv_dev_fops,
>> +	.mode = 600,
>> +};
> For the default mode, I think we want to keep it the same as that for 'kvm'.
> 

KVM doesn't specify a mode here. Not sure how it gets set.

> - Sunil
>