On Fri, Jan 26, 2018 at 05:34:28PM +0000, Michael Kelley (EOSG) wrote:
> > -----Original Message-----
> > From: Greg KH [mailto:[email protected]]
> > Sent: Thursday, January 25, 2018 2:00 AM
> > To: Michael Kelley (EOSG) <[email protected]>
> > Cc: [email protected]; [email protected]; 
> > [email protected];
> > [email protected]; [email protected]; [email protected];
> > [email protected]; [email protected]; Stephen 
> > Hemminger
> > <[email protected]>; KY Srinivasan <[email protected]>; 
> > [email protected];
> > [email protected]
> > Subject: Re: [PATCH v2 char-misc 1/1] Drivers: hv: vmbus: Implement Direct 
> > Mode for stimer0
> > 
> > On Mon, Jan 22, 2018 at 03:29:29PM -0700, [email protected] 
> > wrote:
> > > +/*
> > > + * If false, we're using the old mechanism for stimer0 interrupts
> > > + * where it sends a VMbus message when it expires. The old
> > > + * mechanism is used if Direct Mode is explicitly disabled
> > > + * by the module parameter, or on older versions of Hyper-V
> > > + * that don't support Direct Mode. While Hyper-V provides
> > > + * four stimer's per CPU, Linux uses only stimer0.
> > > + */
> > > +static bool direct_mode_enabled = true;
> > > +module_param(direct_mode_enabled, bool, 0444);
> > > +MODULE_PARM_DESC(direct_mode_enabled,
> > > +                 "Set to N to disable stimer Direct Mode.");
> > 
> > Ick ick ick.  How is a distro or user supposed to know if/when to enable
> > this and not to enable it?  This isn't ok, can you please make this
> > "automatic" to always do the right thing based on what it is running on?
> 
> To be clear, this patch already does the "automatic" thing based on the
> capabilities of the hypervisor.  But it's often handy to be able to override
> the automatic behavior without having to rebuild the kernel.

Then put the option somewhere else.  sysfs, debugfs, somewhere else.
Never a module parameter please, not for new code.

thanks,

greg k-h
_______________________________________________
devel mailing list
[email protected]
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel

Reply via email to