Hello, James. On Tue, Sep 09, 2014 at 03:46:23PM -0700, James Bottomley wrote: > If you want the return of an individual device probe a log scraper gives > it to you ... and nothing else does currently. The advantage of the > prink in dd.c is that it's standard for everything and can be scanned > for ... if you take that out, you'll get complaints about the lack of > standard messages (you'd be surprised at the number of enterprise > monitoring systems that actually do log scraping). Why would a log scaper care about which task is printing the messages? The printk can stay there. There's nothing wrong with it. Log scapers tend to be asynchronous in nature but if a log scraper wants to operate synchronously for whatever reason, it can simply not turn on async probing. > OK, so we just fire and forget in userland ... why bother inventing an > elaborate new infrastructure in the kernel to do exactly what > > modprobe <mod> & > > would do? I think the argument there is that the issuer wants to know whether such operations succeeded or not and wants to report and record the result and possibly take other actions in response. We're currently mixing wait and error reporting for one type of operation with wait for another. I'm not saying it's a fatal flaw or anything but it can get in the way. Thanks. -- tejun -- 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
