bktr(4) risk?
John-Mark Gurney
gurney_j at resnet.uoregon.edu
Mon Oct 9 17:43:39 PDT 2006
Jonathan Chen wrote this message on Mon, Oct 09, 2006 at 19:39 -0400:
> On Mon, Oct 09, 2006 at 04:26:50PM -0700, John-Mark Gurney wrote:
> > Jonathan Chen wrote this message on Mon, Oct 09, 2006 at 17:37 -0400:
> > > doesn't seem too useful a task for a video capture card to be doing.
> > > Perhaps we should put a test for write access in there or just eliminate
> > > the ioctl altogether. It should be noted that the meteor driver had this
> > > ioctl ifdef'ed out prior to its removal.
> >
> > Hmmm... I think I'll go ahead and put in a compatibility ioctl based
> > on the way I did the zoran driver, and schedule the removal of the
> > ioctl..
>
> Zoran driver? Can I have a pointer or a summary of what you did there so I
> can do the same to meteor(4)?
http://people.freebsd.org/~jmg/zoran.html
There is a function verify_contig in zr_os.c, but we should teach
meteor(4) and friends how to use bus_dma to do the buffer now that
I think about it... The work that I do to verify that the buffer
is contiguous should be done by bus_dma...
We should make the user process mmap the video buffer, and then pass
the user's address to the driver... Using a properly crafted uio
struct, you can use bus_dmamap_load_uio to get the correct physical
address of the buffer to program the card with... You can create a
tag w/ only 1 segment to ensure that the mapping will be contigious...
--
John-Mark Gurney Voice: +1 415 225 5579
"All that I will do, has been done, All that I have, has not."
More information about the freebsd-hackers
mailing list