[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <YEvQ6z5WFf+F4mdc@lunn.ch>
Date: Fri, 12 Mar 2021 21:36:59 +0100
From: Andrew Lunn <andrew@...n.ch>
To: "Hsu, Chiahao" <andyhsu@...zon.com>
Cc: netdev@...r.kernel.org, wei.liu@...nel.org, paul@....org,
davem@...emloft.net, kuba@...nel.org,
xen-devel@...ts.xenproject.org
Subject: Re: [net-next 1/2] xen-netback: add module parameter to disable
ctrl-ring
On Fri, Mar 12, 2021 at 04:18:02PM +0100, Hsu, Chiahao wrote:
>
> Andrew Lunn 於 2021/3/12 15:52 寫道:
> > CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
> >
> >
> >
> > On Thu, Mar 11, 2021 at 10:59:44PM +0000, ChiaHao Hsu wrote:
> > > In order to support live migration of guests between kernels
> > > that do and do not support 'feature-ctrl-ring', we add a
> > > module parameter that allows the feature to be disabled
> > > at run time, instead of using hardcode value.
> > > The default value is enable.
> > Hi ChiaHao
> >
> > There is a general dislike for module parameters. What other mechanisms
> > have you looked at? Would an ethtool private flag work?
> >
> > Andrew
>
>
> Hi Andrew,
>
> I can survey other mechanisms, however before I start doing that,
>
> could you share more details about what the problem is with using module
> parameters? thanks.
It is not very user friendly. No two kernel modules use the same
module parameters. Often you see the same name, but different
meaning. There is poor documentation, you often need to read the
kernel sources it figure out what it does, etc.
Ideally, you want a mechanism which is shared by multiple drivers and
is well documented.
Does virtio have the same problems? What about VmWare? HyperV? Could
you make a generic solution which works for all these technologies?
Is this just a networking problem? Or does disk, graphics etc, need
something similar?
Andrew
Powered by blists - more mailing lists