On 24.02.2019 22:26, Florian Fainelli wrote:
>
>
> On February 24, 2019 9:04:55 AM PST, Andrew Lunn <and...@lunn.ch> wrote:
>>> The added difficulty here and the reason why Andrew went with the
>>> approach that is used by the code currently is because neither do the
>>> CPU or DSA ports are backed by a net_device. It is somewhere on my
>> TODO
>>> to permit the use of PHYLINK without the need of a net_device to
>> cover
>>> those specific DSA cases unless we just brute force the whole thing
>> and
>>> allocate a net_device structure but not register that net_device? Yes
>> in
>>> fact, why don't we do that?
>>
>> Hi Florian
>>
>> At the moment, we are using a phydev which is not connected to a
>> MAC. That is rather odd, but the phylib maintainers mostly know about
>> this, and keep an eye out for changes which might break any
>> assumptions. And the phylib API is quite small.
>
> I would argue that this very thread is a proof against your argument since we
> all failed to predict that Heiner's changes would change those assumptions.
> Having a certain of assumptions is fine but given all the recent PHYLIB
> helpers that have been added I am not sure how well that will scale.
>
>>
>> How many assumptions are going to break with a netdev which is not
>> registered? The API is much bigger, more people hack on it, and it is
>> going to be much harder to review changes to make sure assumptions are
>> not changed.
>
> A non registered net_device appears easier to manage and debug since there is
> state tracking all over the network stack for those cases.
>
>>
>> If we are going to do something odd, we should keep the scope as small
>> as possible.
>
> Hence my suggestion to allocate a dummy net_device object just so calls to
> netif_carrier_{on,off} (and possibly more in the future) do nothing. I don't
> think that teaching either PHYLIB or PHYLINK about a NULL net_device is going
> to scale really well over time nor make it easier for respective
> maintainers. If we make the net_device optional, it will be harder to review
> changes as well as make sure that we do not create locking/object
> interactions issues.
>
> Another approach could be to define a minimal network port object (struct
> devlink, maybe?) which could be used independently from a net_device, or a
> lightweight net_device with no visibility into existing namespaces. None of
> these ideas are new though and would probably require several cycles to get
> done right.
>
> Heiner, Russell, which approach would you take?
>
Given my 2 days of experience with DSA (feels like 3 already) I would like to
spend few more minutes on thinking before I answer.
Heiner
