Cathy Zhou wrote: > >> >> > 3. Another problem is that when both forms of autopush >> configuration exist, > if we apply both autopush settings, it might >> leads to incorrect behavior. So > that I'd like only apply the >> per-link autopush setting in that case. Is this > acceptable? >> >> That makes sense to me. >> > I found it is impossible to implement this for style-2 open. When > accessing a device using style-2 opening approach, it is impossible to > know which link is accessed in stropen(), so that it is impossible to > prevent autopush the traditional autopush(1M) modules at that time. >
After thinking about this more, I decided to change the original proposal, and do the following: When opening a network device: a. If there is any per-link autopush configuration, push modules based on that, and ignore per-driver autopush configuration; otherwise b. Found the *active" per-driver autopush configuration based on this device node's "real" physical dev_t. I say "real" here because in the case of non-GLDv3 driver, the dev_t is the softmac node's dev_t. In that case, we need to automatically push modules based on the dev_t of the real device (the softmac's underlying device). c. When softmac opens the underlying driver, it pops all the autopushed modules in between. Because those modules will be pushed over the softmac device in step b. d. Get rid of the whole "dladm migrate-autopush" support. By doing the above, we will safely apply all the old autopush(1M) configuration, including those not defined in /etc/iu.ap. But note that those per-driver autopush configuration will not be migrated to the per-link autopush configuration. (it won't be shown by show-linkprop -p autopush). I made the choice based on the following thoughts: The reason that we need migrating the old autopush(1M) configuration to the new one is that because of the Nemo unification project (which opens the lower the legacy device as the lower stream), it might cause some unexpected result if modules are pushed in the lower stream (between softmac and the underlying driver). Also, it is confusing and maybe conflicting to have two sets of autopush setting at the same time. But the current "dladm migratie-autopush" approach doesn't solve any of the two problem. It doesn't remove the confusion either. The old "migrate-autopush" is not real migration, because we have to keep the old set of autopush setting, as administrators might choose to configure autopush not based on "/etc/iu.ap". Thanks - Cathy
