mmap on freebsd vs linux

[Danny Pansters]

I'm not really an expert on this but here goes...

On Wednesday 18 April 2007 18:05:44 usleepless at gmail.com wrote:
> Hi All,
>
> i am looking into implementing a piece of the V4L interface. this
> involves mmap'ing from userspace into kernelspace.
>
> in mplayer, this is what is called:
>
> tvi_v4l2.c:
> "
> priv->map[i].addr = mmap (0, priv->map[i].buf.length, PROT_READ |
>                                   PROT_WRITE, MAP_SHARED,
> priv->video_fd,priv->map[i].buf.m.offset);
> "
>
> the file descriptor parameter is the file descriptor of the opened
> capture device. the offset parameter should be filled in by the opened
> device.

A device won't fill in anything. A driver must.

> does mmap work on freebsd as it works on linux? ie: can i mmap any
> device? are there constraints on the device which should be met?

You can mmap anything, but only if you get a (frame-) buffer of known size 
will it be useful to actually do something with it. The mplayer code probably 
takes the offset from what it knows about capture size (which for PAL/NTSC is 
known if also the YUV output type is known). You also need some signalling to 
know when to read the (new) buffer data again.

I'd also advise to cast the address to caddr_t and the offset to off_t types. 
Will probably help compiling on 64 bits archs. And using both  PROT_READ and 
PROT_WRITE seems non-sensical. You only want to read the buffer not 
(directly) write to it, unless perhaps if it contains more than just the 
framedata. That would seem bad design to me though, if you have to write to 
the same buffer that also contains data that you absolutely dont want to 
overwrite.

I'm not familiar with v4l but simple and working mmap examples for FreeBSD 
with bktr and for saa are here: 
http://freebsd.ricin.com/kbtv/kbtv-1.2.4/bt848/bt848.c and 
http://freebsd.ricin.com/kbtv/kbtv-1.2.4/saa/saa.c 

Scroll down to Framebuffer. The buffer size is determined by the frame pixel 
size and by which YUV type is being used. The latter determines how much data 
is used on average per pixel, so you can calculate the datasize.

See how bktr has offset 0 while saa has offset SAA_MMAP_T0_OFFSET. Both are 
what they are because of how their drivers are organized.

See mmap(2) for the nitty-gritty on mmap. In general: if it segfaults or 
spontaneously reboots you likely made a mistake with the buffer size or 
offset :)

HTH,

Dan