Date: Sun, 14 Apr 2002 12:02:52 -0700 From: Peter Haight <peterh@sapros.com> To: hardware@freebsd.org Subject: Reading from the USB ugen device. Message-ID: <200204141902.g3EJ2rRg031891@wartch.sapros.com>
next in thread | raw e-mail | index | archive | help
I've been working with an application called coldsync to get my Sony Clie to sync to my computer. I'm using FreeBSD-4.5-STABLE. I've gotten it to work, but I ran into an issue I don't understand and I'd like to know what's going on. The software begins by sending a USB_DISCOVER on usb0 and then tries to open /dev/ugen0. If that succeeds it checks to make sure the device is the Clie (using USB_GET_DEVICEINFO) and then it sends a vendor information request over the control endpoint. From the information it gets back from that it figures out which endpoint to open and then it opens that one (Usually ugen0.2). Then it sends the USB_SET_SHORT_XFER on that device. The original author of the code, had a routine which reads data from the ugen0.2 device 1024 bytes at a time. A comment in the code indicates that it needs to make sure it reads any data available because the kernel isn't buffering anything. Well, that would work for about 8 reads (read(2)) and if I ran it under gdb, each of those reads would actually just return whatever amount of data we were expecting according to the protocol. Probably about 6-100 bytes at a time. Then it would just block indefinitely when I was expecting 64 bytes. I managed to fix it by getting rid of the 1024 byte reads and just reading whatever I was expecting. Once I made that change, it didn't block on that read and then went on to read the rest of about 6MB from the device. I don't get it. My only guess is that when doing it the other way the timing changes subtly so that I'm not in the read when the next set of data comes and since it is unbuffered it just gets discarded by the kernel. The problem with this theory is that I've not changed the part of the code that manages the buffer. So I don't really see how the timing could be different because if I run it with the buffering on, it never gets a read longer than what I was expecting. The actual read lengths are exactly the same whether I request 1024 bytes or the number of bytes I'm expecting, but if I use 1024 it eventually blocks. Anyway, this all has me worried about timing with an unbuffered device. I don't have a good understanding of what's going on, so I'm not sure what's a good way to deal with this issue. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hardware" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200204141902.g3EJ2rRg031891>