On (10/11/07 17:46), Artem Kachitchkine wrote: > > That's correct. This is why in my earlier brute-force version, > > I was doing property cleanup/restore in mac_stop/mac_start (the detach > > is controlled by the DDI framework). But I thought that your changes > > also took care of this by doing the mac_prop_fini, and creating the > > mac prop if needed in mac_start? > > Yes, bge allocates and then releases its property handle during attach. > But in any case, I don't see how that's related to the problem in hand. > Property handles are managed completely separately from everything else > - separate hash, separate access functions.
I think I know where the divergence happened. In mac_start, you call mac_prop_load with the mi_drvname- in my previous brute-force hack, I would pass in null, so that dladm would go and actually configure each property (i.e, do a SETPROP) instead of just loading the prop list. When you pass the drvname, the dladmd->libdladm interaction sets DLD_INIT_LINK in the pr_flags, so the mc_setprop is bypassed. The clean way to fix this is to pass new flags up the door-call to signal to the dladmd that we want to do both the setprop and the property update. --Sowmini
