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@secunet.com Ammonstraße 74, 01067 Dresden www.secunet.com