>> 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 _______________________________________________ networking-discuss mailing list [email protected]
