On Wed, 16 Jan 2013, Tejun Heo wrote: > Hello, Alan. > > On Wed, Jan 16, 2013 at 12:01:53PM -0500, Alan Stern wrote: > > > The problem here is that "flush everything which comes before me" is > > > used to order async jobs. e.g. after async jobs probe the hardware > > > they order themselves by flushing before registering them, so unless > > > > I don't fully understand this example. What is the point -- to make > > sure that asynchronously probed devices are registered in the order of > > their discovery? > > People still want devices to be numbered to their physical ports and > so on, so we keep the registeration order the same as natural > (whatever that means) hardware order. > > > If so, here's how to do it safely: Start up the async jobs in reverse > > order of discovery. Have each job acquire a cookie when it starts. > > Then each job needs to wait only for tasks that started after its > > cookie was issued. > > It's a bit clumsy but yeah I guess it could work. > > > > There aren't too many which use async anyway so changing stuff > > > shouldn't be too difficult but I think the simpicity or dumbness is > > > one of major attractions of async, so it'd be nice to keep things that > > > way and the PF_USED_ASYNC hack seems to be able to hold things > > > together for now. > > > > Nesting won't matter for the chronological approach. I really think > > you should consider it more fully. It's not a hack, and it doesn't > > need to be complicated. > > There is benefit to the current dumb implementation in that drivers > can use it without thinking too much, but yeah it could be that the > flushing range limit isn't too much of restriction on top. I don't > know. At this point, I'd prefer to remove request_module() from > elevator init path for the problem at hand. If we need something more > involved, changing cookie usage rules definitely seems like an option. A simpler approach might be to leave the existing synchronization mechanisms as they are, and use the chronological approach only for the case of loading a module (or wherever else someone wants to use it). Alan Stern -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
