[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <a17e5ad7-e79d-0e83-43d3-0c06b0400ed6@gmail.com>
Date: Tue, 3 Apr 2018 08:33:11 -0600
From: David Ahern <dsahern@...il.com>
To: Jiri Pirko <jiri@...nulli.us>
Cc: Ido Schimmel <idosch@...lanox.com>, netdev@...r.kernel.org,
davem@...emloft.net, jiri@...lanox.com, petrm@...lanox.com,
mlxsw@...lanox.com
Subject: Re: [PATCH net-next 09/11] devlink: convert occ_get op to separate
registration
On 4/3/18 1:32 AM, Jiri Pirko wrote:
> Fri, Mar 30, 2018 at 04:45:50PM CEST, dsahern@...il.com wrote:
>> On 3/29/18 2:33 PM, Ido Schimmel wrote:
>>> From: Jiri Pirko <jiri@...lanox.com>
>>>
>>> This resolves race during initialization where the resources with
>>> ops are registered before driver and the structures used by occ_get
>>> op is initialized. So keep occ_get callbacks registered only when
>>> all structs are initialized.
>>
>> Why can't the occ_get handler look at some flag in an mlxsw struct to
>> know if the system has initialized?
>>
>> Separate registration here is awkward. You register a resource and then
>> register its op later.
>
> The separation is exactly why this patch is made. Note that devlink
> resouce is registered by core way before the initialization is done and
> the driver is actually able to perform the op. Also consider "reload"
That's how you have chose to code it. I hit this problem adding devlink
to netdevsim; the solution was to fix the init order.
> case, when the resource is still registered and the driver unloads and
> loads again. For that makes perfect sense to have that separated.
> Flag would just make things odd. Also, the priv could not be used in
> that case.
>
I am not aware of any other API where you invoked the register function
at point A and then later add the operations at point B. In every API
that comes to mind the ops are part of the register.
I am sure there are options for you to fix the init order of mlxsw
without making the devlink API awkward.
Powered by blists - more mailing lists