[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <20200102.162941.1933071871521624803.davem@davemloft.net>
Date: Thu, 02 Jan 2020 16:29:41 -0800 (PST)
From: David Miller <davem@...emloft.net>
To: haiyangz@...rosoft.com
Cc: sashal@...nel.org, linux-hyperv@...r.kernel.org,
netdev@...r.kernel.org, kys@...rosoft.com, sthemmin@...rosoft.com,
olaf@...fle.de, vkuznets@...hat.com, linux-kernel@...r.kernel.org
Subject: Re: [PATCH V3,net-next, 0/3] Add vmbus dev_num and allow netvsc
probe options
From: Haiyang Zhang <haiyangz@...rosoft.com>
Date: Tue, 31 Dec 2019 14:13:31 -0800
> Add dev_num for vmbus device based on channel offer sequence.
> User programs can use this number for nic naming.
> Async probing option is allowed for netvsc. Sync probing is still
> the default.
I don't like this at all, sorry.
If 4 devices get channels we will have IDs 1, 2, 3, 4.
Then if channel 3 is taken down, the next one will get 3 which
is not in order any more.
It is not even clear what semantics these numbers have in any
particular sequence or probe situation.
You have to use something more persistent across boots to number
and strictly identify these virtual devices.
I'm not applying this.
Powered by blists - more mailing lists