Thanks a lot for the detailed reply! >> For certain values of `X` there is a significant difference in size >> between the two files, which I don't expect. >> >> A read call to the driver does the following: >> 1. `mutex_lock_interruptible(iolock)` >> 2. `usb_bulk_msg(dev, pipe, buf, X, timeout)` >> 3. `mutex_unlock(iolock)` >> 4. `copy_to_user(buf)` > > What are these values of X that cause differences here? Starting around 1k character device A gets more data until it turns over at around 4K. Request size from 10K yield the expected data rates. Character device A is a "real" random source and returns data much slower than device B, which is a pseudo random source. > But if you are trying to somehow create a real api that you have to > enforce the passing off of writing data from two different character > devices in an interleaved format, you are doing this totally wrong, as > this is not going to work with a simple mutex, as you have found out. As mentioned above, the USB device provides two different streams of random. But the device can process only one request at a time. Also I didn't want to have too much dynamic memory allocation, because I would need to allocate up to 64KB kernel memory on each open. That's because the USB device is designed to provide up to 64K of random in a single "request". A request has a header and footer "protecting" the request as a whole from data confusion. To make things simpler I decided to just allow one user space process at a time for each source - which is enough for our application. But yes, that could probably also got to user space. > So, I really haven't answered your question here except to say, "it's > complicated" and "you aren't measuring what you think you are measuring" :) Ok, I see. Thanks, Martin Christian -- Dipl.-Inf. Martin Christian Senior Berater Entwicklung Hardware secunet Security Networks AG Tel.: +49 201 5454-3612, Fax +49 201 5454-1323 E-Mail: martin.christian@xxxxxxxxxxx Ammonstraße 74, 01067 Dresden www.secunet.com
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
