Michael Reed wrote: > > James Bottomley wrote: >> Since the rest of >> our infrastructure is already event driven, or migrating that way, I >> really don't see value in introducing an anomaly like this purely for >> fibre channel. > > It's tough on fibre channel, being first. :) > > Among the benefits of this patch is the purchase of time. With the fc > infrastructure the way it is, you're assured of forcing developers to > "publish or perish". That may be the intended desire. It just doesn't > seem fair to the users who have to deal with this. It makes sense to > me to implement the event driven infrastructure in such a way that > it's more complete when released. If infrastructure is going to be > removed, then "applications" have to be adjusted to accommodate this. > It shouldn't be, oh by the way, your driver/app is now broken, hurry up > and fix it or your users will complain. [End Of Rant]. My patch > buys time. Change the default so that the remove on disconnect has > to be consciously overridden. Remove the variable when the supporting > infrastructure is in place. Put out a message indicating that the > option of not removing the infrastructure is "going away" in a future > release. Provide an orderly transition. Insure domestic tranquility. > Promote the general welfare. :) I'm happy to adjust the patch > to accommodate any of these suggestions if they are deemed acceptable. > And I can only _strongly_ agree with Mike here. Yes, the infrastructure is moving towards dynamic device configuration. But no, we're not there yet. Not by a long way. Neither of the current volume managers (ie LVM2, EVMS, and even md to some extend) are capable of dynamic reconfiguration. Of course they sort of work nowadays, but the general idea of LVM2 and EVMS is still that _all_ devices are available during setup. And I don't even want to _think_ of the implications of running 'vgscan' from a udev rule. So Mike's patch would allow those application to run properly for the time being. In general I agree with the dev_loss_tmo mechanism. But by enforcing it we'll only make it easier for the developers of LVM2 et al to put the blame on us (on the grounds of 'you broke it, you fix it') instead of coaxing them to change their applications to accept dynamic device configuration. Cheers, Hannes -- Dr. Hannes Reinecke hare@xxxxxxx SuSE Linux Products GmbH S390 & zSeries Maxfeldstraße 5 +49 911 74053 688 90409 Nürnberg http://www.suse.de - : send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
