Re: [PATCH 05/12] net: xen-netback: xenbus: Demote nonconformant kernel-doc headers
On Wed, Nov 04, 2020 at 09:06:03AM +, Lee Jones wrote: > Fixes the following W=1 kernel build warning(s): > > drivers/net/xen-netback/xenbus.c:419: warning: Function parameter or member > 'dev' not described in 'frontend_changed' > drivers/net/xen-netback/xenbus.c:419: warning: Function parameter or member > 'frontend_state' not described in 'frontend_changed' > drivers/net/xen-netback/xenbus.c:1001: warning: Function parameter or member > 'dev' not described in 'netback_probe' > drivers/net/xen-netback/xenbus.c:1001: warning: Function parameter or member > 'id' not described in 'netback_probe' > > Cc: Wei Liu > Cc: Paul Durrant > Cc: "David S. Miller" > Cc: Jakub Kicinski > Cc: Alexei Starovoitov > Cc: Daniel Borkmann > Cc: Jesper Dangaard Brouer > Cc: John Fastabend > Cc: Rusty Russell > Cc: xen-devel@lists.xenproject.org > Cc: net...@vger.kernel.org > Cc: b...@vger.kernel.org > Signed-off-by: Lee Jones Reviewed-by: Andrew Lunn Andrew
Re: [PATCH 08/12] net: xen-netfront: Demote non-kernel-doc headers to standard comment blocks
On Wed, Nov 04, 2020 at 09:06:06AM +, Lee Jones wrote: > Fixes the following W=1 kernel build warning(s): > > drivers/net/xen-netfront.c: In function ‘store_rxbuf’: > drivers/net/xen-netfront.c:2416:16: warning: variable ‘target’ set but not > used [-Wunused-but-set-variable] > drivers/net/xen-netfront.c:1592: warning: Function parameter or member 'dev' > not described in 'netfront_probe' > drivers/net/xen-netfront.c:1592: warning: Function parameter or member 'id' > not described in 'netfront_probe' > drivers/net/xen-netfront.c:1669: warning: Function parameter or member 'dev' > not described in 'netfront_resume' > drivers/net/xen-netfront.c:2313: warning: Function parameter or member 'dev' > not described in 'netback_changed' > drivers/net/xen-netfront.c:2313: warning: Function parameter or member > 'backend_state' not described in 'netback_changed' > commit 8ed7ec1386b646130d80d017ecd4716f866ea570 Author: Andrew Lunn Date: Sat Oct 31 19:04:35 2020 +0100 drivers: net: xen-netfront: Fixed W=1 set but unused warnings Already in net-next. Andrew
Re: [PATCH 2/8] net: xen-netback: xenbus: Demote nonconformant kernel-doc headers
On Thu, Nov 26, 2020 at 01:38:47PM +, Lee Jones wrote: > Fixes the following W=1 kernel build warning(s): > > drivers/net/xen-netback/xenbus.c:419: warning: Function parameter or member > 'dev' not described in 'frontend_changed' > drivers/net/xen-netback/xenbus.c:419: warning: Function parameter or member > 'frontend_state' not described in 'frontend_changed' > drivers/net/xen-netback/xenbus.c:1001: warning: Function parameter or member > 'dev' not described in 'netback_probe' > drivers/net/xen-netback/xenbus.c:1001: warning: Function parameter or member > 'id' not described in 'netback_probe' > > Cc: Wei Liu > Cc: Paul Durrant > Cc: "David S. Miller" > Cc: Jakub Kicinski > Cc: Alexei Starovoitov > Cc: Daniel Borkmann > Cc: Jesper Dangaard Brouer > Cc: John Fastabend > Cc: Rusty Russell > Cc: xen-devel@lists.xenproject.org > Cc: net...@vger.kernel.org > Cc: b...@vger.kernel.org > Signed-off-by: Lee Jones Reviewed-by: Andrew Lunn Andrew
Re: [net-next 1/2] xen-netback: add module parameter to disable ctrl-ring
On Thu, Mar 11, 2021 at 10:59:44PM +, 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
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 +, 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
Re: [net-next 1/2] xen-netback: add module parameter to disable ctrl-ring
> > At the end, it will be more granular module parameter that user still > > will need to guess. > I believe users always need to know any parameter or any tool's flag before > they use it. > For example, before user try to set/clear this ctrl_ring_enabled, they > should already have basic knowledge about this feature, > or else they shouldn't use it (the default value is same as before), and > that's also why we use the 'ctrl_ring_enabled' as parameter name. To me, it seems you are fixing this problem in the wrong place. As a VM user in the cloud, i have no idea how the cloud provider needs the VM configured to allow the cloud provider to migrate the VM to somewhere else in the bitbarn. As the VM user, it should not be my problem. I would expect the cloud provider to configure the VM host to only expose facilities to the VM which allows it to be migrated. This is a VM host problem, not a VM problem. Andrew
