On Thu, Mar 20, 2008 at 10:16 AM, Garrett D'Amore <[EMAIL PROTECTED]> wrote: > I think you've already seen responses to this from others. > > GLDv2 used to call this, so NIC drivers do not have to start their > attach with their unicast addresses programmed. > > GLDv3 no longer calls this on attach, only if the administrator attempts > to change the MAC address. This means your driver must arrange to start > with its own unicast address at attach/registration time. This is a > change for GLDv3.
Gotcha. It looks like I placed the mac_register_t initialization too early: I replaced the GLDv2 gld_mac_info_t init with the appropriate GLDv3 mac_register_t init. I had made an incorrect assumption that everything mac_register_t relied upon was initialized; I had not checked if dnetp->curr_macaddr had been initialized (it had not, that occurs later on in the attach). I think I'll also move the mac_alloc call closer to mac_register (similar to afe_attach). It seems to be a bit cleaner in the event of failure, and also circumvents initialization bugs like the one described above. There is also the added benefit of all GLDv3 initialization code being in close proximity to each other. I'll get this cleaned up tonight, and (hopefully) be one step closer to an actual review. Thanks all, Steve _______________________________________________ networking-discuss mailing list [email protected]
