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