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

[Cathy Zhou]

>> This leads to another two questions:
>>
>> a. Do you expect legacy physical drivers to use this interface, and how?
> 
> Nope.
> 
I suppose that the dip passed into mac_prop_init() function for legacy drivers 
would be the dip of the physical device, instead of the softmac_dip?

>> 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.
> 
Well, I would think that all callers would just set m_instance to 0.

>>> 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 think you actually are using the device name, instead of the mac name. 
Assuming a ce device, do you use device name (ce0), or a mac name (softmacxxxx)?

> Given that mac_open happens before mac_start, I think yes, this should 
> be possible. I'll give it a try.
> 
Thank you!
- Cathy