Ben Bridgwater wrote: > Gerd Knorr wrote: > > > The current v4l2 specs says drivers should support non-blocking reads but > > may refuse partial reads if it is "inefficient to implement". This > > combination simply doesn't make sense to me. IMHO we should pick one > > of the more useful combinations: make partial reads mandatory or drop > > non-blocking I/O support for read(). > > If this is the choice, I'd much rather have the non-blocking read() with > select support, as this seems much more useful (for IO integration). I > can't see the use for partial reads. Ahem, no. Looks like a misunderstanding. I'll try again: With bttv I can let the bt848/878 dma the video data directly to userspace. To do this I need (a) a destination address in userspace and (b) enouth space to store the whole frame there. Because of (a) this doesn't work with non-blocking I/O (I don't have the destination address yet at the time I start DMA). Because of (b) partial reads do not work. I can also put the whole frame into a bounce buffer in kernel memory. If I handle read() syscalls this way I have no problems to deal with non-blocking I/O (because the dma will go to the bounce buffer and I don't need the destination address yet when I start the DMA). And partial reads are no problem too, because it makes no difference for me whenever I copy the bounce buffer in one big or many small chunks to userspace. So IMHO it would be useful to either: - require driver do support *both* non-blocking I/O and partial read()s or - allow drivers to support only blocking, full-frame read()s. Gerd -- Gerd Knorr <kraxel@xxxxxxxxxxx> -- SuSE Labs, Außenstelle Berlin
