[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20231118093849.14e36043@kernel.org>
Date: Sat, 18 Nov 2023 09:38:49 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Stephen Hemminger <stephen@...workplumber.org>
Cc: Long Li <longli@...rosoft.com>, "longli@...uxonhyperv.com"
<longli@...uxonhyperv.com>, KY Srinivasan <kys@...rosoft.com>, Haiyang
Zhang <haiyangz@...rosoft.com>, Wei Liu <wei.liu@...nel.org>, Dexuan Cui
<decui@...rosoft.com>, "David S. Miller" <davem@...emloft.net>, Eric
Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
"linux-hyperv@...r.kernel.org" <linux-hyperv@...r.kernel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH net-next v4] hv_netvsc: Mark VF as slave before exposing
it to user-mode
On Wed, 15 Nov 2023 08:14:06 -0800 Stephen Hemminger wrote:
> Jakub is right that in an ideal world, this could all be managed by
> userspace. But the management of network devices in Linux is a
> dumpster fire! Every distro invents there own solution, last time
> I counted there were six different tools claiming to be the
> "one network device manager to rule them all". And that doesn't
> include all the custom scripts and vendor appliances.
To be clear, I thought Long Li was saying that the goal is work around
cases where VF is probed before netvsc. That seems like something that
can be prevented by the hypervisor.
Powered by blists - more mailing lists