On Fri, Apr 21 2017, Felipe Balbi wrote: > why would it have to do that? We would allocate a new struct > usb_request, allocate a new buffer, copy_from_user() and > usb_ep_queue(). Why would we return -EAGAIN? Nvm. Of course you’re right. >> What if user space doesn’t want to read? If kernel space keeps an >> active out request, user space has no control whether it can not respond >> to an out request. > I'm not sure this is something we should care about. Note how every > gadget driver, apart from f_fs, pre-queues several IN and OUT requests. >> Maybe this is theoretical, but I wouldn’t be surprised if there was an >> USB protocol of some kind where this matters. > I doubt there would be any protocol relying on NAKs. Me too, but I’ve seen crazier things… And as I’ve said, I’m all for a full O_NONBLOCK implementation, but to bring it back to original question, OP’s issue is solved by existing aio support, so those are orthogonal. -- Best regards ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ «If at first you don’t succeed, give up skydiving» -- 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
