[brussels-dev] [networking-discuss] code review Brussels persistence

[Artem Kachitchkine]

> If so, please make it clear that this is only used for physical links.

Okay.

> This leads to another two questions:
> 
> a. Do you expect legacy physical drivers to use this interface, and how?

Nope.

> b. Can we remove the second m_instance argument? As I said, it is impossible 
> for a driver to specify it if it is different from the instance number of the dip.

During design review, we agreed to do it this way just to be consistent 
with mac_register(). I would just leave it there, why split hairs when 
we can not to.

>> aspect that bothers me is interaction of dlmgmtd with partially attached
>> devices - i.e. the attach(9E)->mac_prop_init->mac_prop_load->... chain.
>>   Do you know of any existing kernel functions to translate macnames
>> into devnames and vice versa?
>>
> No, there is no existing functions can do this. Especially if it is before 
> _attach(), when a mac is not even registered, and mac name is not determined yet.

Exactly. That's the reason I'm using macname, because at this early 
stage it's the only thing available for sure. Otherwise we get into a 
deadlock.

> I understand that this RFE is for this purpose. But I have incorrectly thought 
> that datalink autopush must be configured before plumbing.
> 
> But note mac_start() will be moved to be part of DL_BIND_REQ processing soon 
> (as part of the Clearview softmac fast-path work). In my opinion, mac_start() 
> should have been called as the result of DL_BIND_REQ, as only from then on, 
> the driver is allowed to transfer data.
> 
> So my question changes to: Is it possible to move mac_prop_load() call from 
> mac_start() to mac_open()?

Given that mac_open happens before mac_start, I think yes, this should 
be possible. I'll give it a try.

-Artem