From mboxrd@z Thu Jan 1 00:00:00 1970 MIME-Version: 1.0 In-Reply-To: <540358d04e4b2c13d1af3f248ff37b7a@quanstro.net> References: <40e9be7c0a41006682219e41b077f806@hamnavoe.com> <540358d04e4b2c13d1af3f248ff37b7a@quanstro.net> Date: Sun, 19 Jul 2009 17:14:10 +0200 Message-ID: <8ccc8ba40907190814g652f88f6u817a3085b563fdf7@mail.gmail.com> From: Francisco J Ballesteros To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [9fans] new usb stack and implicit timeouts Topicbox-Message-UUID: 2744c852-ead5-11e9-9d60-3106f5b1d025 that's what I understood. In any case I'll run the code through all devices I have before sending any usb patch. I'm still not sure that some disks currently working won't cease working if they do their own timeouts. I just want to be sure. I placed timeouts there only when I found uncooperative devices, in practic= e. In theory, not even ctl timeouts are needed. (I should get crc/timeout errors even in those cases according to the std). but I have learned the hard way not to trust any usb std. On Sun, Jul 19, 2009 at 4:32 PM, erik quanstrom wrot= e: >> > =C2=A0isn't it easier to set >> > up time timeout at the beginning? >> >> Not if you use normal read/write to talk to usb endpoints (which >> seems to me a Good Thing). =C2=A0Normal read/write system call doesn't >> have a timeout argument. > > do you mean "normal read/write" vs. an rpc protocol, say, like > /dev/sdXX/raw? > > - erik > >