An output queue also reduces the work required by the miner dramatically.
The BFL SC code we wrote has an independent thread that simply checks for results and times those checks to attempt to minimise the polling - this makes the process of getting results optimal in the extreme.
If we know the queue is 2 (or 4 or 8 ) in size then we know we only have to poll at most twice per expected result (or even less if the time per result is less than 100ms) to ensure work is getting returned and the queue isn't filling up
If, on the other hand, there is no queue, then we need to poll as required to avoid losing results and to keep synchronisation - and 'as required' can be good or bad depending on how the output works.
I currently have a result queue of 2 items. But when a result occurs I send it off via USB and the queue is mostly in case another result occurs before the first one has been accepted/cleared.
Is there no way with libusb to put a hook on received data so that when something arrives it can callback one of the driver functions? That would seem ideal to me as then you never have to poll - just write a handler for result data as it arrives.
I've coded a variant of the bflsc identify function for klondike. I haven't got back to do more yet. I added an I cmd in firmware to output an identity record with serial# and product code. I'm sure I can get more of the driver functions filled in over the next few days.