> > > A related problem: The API document allows drivers to refuse read()
> > > calls with sizes smaller than a full frame ("a partial frame may be
> > > [ ... ] impractical or inefficient to implement"). Which doesn't
> > > make sense to me, assuming we require the drivers to support
> >
> > Hmmm. Maybe you're right. Am I giving too much discretion to the driver
> > writer?
>
> I'd rather we allowed partial reads, but Im not sure how hard it impacts the
> drivers which are DMA based - I guess this is one for folks like Gerd Knorr
It's a tradeoff. I have two choices to implement that:
(1) dma to userspace. This is what the current devel bttv versions
(0.8.x) do. It's the most efficient way to do it, but the drawback
is that neither non-blocking reads nor partial reads can be handled
this way.
(2) dma to a kernel bounce buffer and copy_to_user() data. No problem
to do non-blocking I/O and partial reads then, but its inefficient
because I need a extra copy for the video data.
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().
Gerd
--
Gerd Knorr <kraxel@xxxxxxxxxxx> -- SuSE Labs, Außenstelle Berlin
