On Thu, 15 Mar 2012, Oliver Neukum wrote: > Am Donnerstag, 15. März 2012, 16:13:08 schrieb Alan Stern: > > On Thu, 15 Mar 2012, Oliver Neukum wrote: > > > > But the command crashing the reader could come from user space, > > > couldn't it? So I am afraid this is no solution. > > > > It is _a_ solution (it allows Wolfgang to print again), just not a > > _perfect_ solution. > > Well, yes, but this solution allows users of the storage device > to mess up the printing. > > > > It seems to me that we > > > need to make the SCSI layer avoid a reset of this device. Then at least > > > the printer would work reliably. > > > > But what happens if somebody does put in a memory card and the card > > reader needs to be reset? Data could get lost. > > But the storage component is buggy. It seems to me that if we have > a device with multiple component and only some of them are buggy, > then the damage should occur to users of the buggy components. > > > A more secure approach would be to prevent usb-storage from binding to > > the card reader at all. But this would have the disadvantage that > > people wouldn't be able to use the card reader even while they weren't > > printing. > > Exactly. > > > I can't think of any perfect solutions. Adding pre_reset and > > post_reset support to usblp would be a good step, but I don't know > > whether it would solve the problem. Probably not. > > It would make matters worse. The meaning of the stream of bytes > transmitted to a printer depends on earlier parts of the stream. > If a reset happens while something is printed, the partial page has > to be discarded and the job restarted. > Neither should we wait for printing to stop, as we could potentially > wait forever. > We'd need a way to refuse a reset. But I don't think that this is worth > doing so. Then what's your suggestion? Leave things as they stand? Or add a way for usb-storage to skip device resets? How would it know whether to do this? 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
