On 11/17/2011 07:41 PM, Zou, Yi wrote: >> >> It doesn't really make any sense to ignore inactive >> devices; the user has already specified which interfaces >> fipvlan should test. >> So instead we should be activating the interfaces before >> sending any FIP request. If nothing has been received >> we can always tear down the interface afterwards. >> > This is really debatable as if it is intentional to ifdown > the interface from anything outside fcoe, then you may end > up bounding up and down the interface...I am not sure how > realistic it is but the current way to bypass inactive one > is a safe bet I think. Alternatively, may be add an option > like '--force-up' at least to warn the user? > Hmm. Can't really see how this scenario could happen. You've seen my other patch for shutting down those interface again, right? (I should probably have send them as a single patch, not two ...)
In any case, with both of them patches we'll be starting the interfaces which are not 'up', and shutting them down afterwards if no response has been received. We will _never_ shut down an interface which we didn't start previously. So yes, there is some sort of race window if someone modifies the interface while fipvlan is running. But this applies to _all_ interfaces fipvlan is running on, so it's not a particular problem introduced by this patch. And again, I fail to see the rationale of _not_ starting up interfaces. The user has specified on which interfaces he wants to run fipvlan on, so one would assume that he _really_ means it. But of course I can add a command line option if you really insist upon. But then I'd like an explanation _why_ we cannot start interfaces per default. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage h...@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) _______________________________________________ devel mailing list devel@open-fcoe.org https://lists.open-fcoe.org/mailman/listinfo/devel
