--- James Bottomley <James.Bottomley@xxxxxxxxxxxx> wrote: > On Tue, 2006-09-26 at 15:05 -0700, Alexis Bruemmer wrote: > > In some cases while hotplugging disks on a system with an expander the > > broadcast primitive will be posted and begin processing before the > > expander change count is updated. This causes the device that triggered > > the broadcast to not be found. > > Thanks; I'll stick this in. > > However, it has always struck me that this broadcast code is fragile > because of the way event processing works. If we get two fairly close > together broadcast events, we'll amalgamate them into a single event and > then stop processing as soon as we find one expander that changed, if > you want to look at sorting that out ... You have to make a clarification: "the way event processing works" means the way it works after you removed all of event processing from my code the way I wrote it, and added a very naive "event processing" if it can be called that. Event processing seems to work just fine with my version of my code the way I maintain it, and the way you had it originally on this list. Just clarifying in case someone gets confused reading the code. > > James > > > - > To unsubscribe from this list: 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 > - To unsubscribe from this list: 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
