I note that at least 5 device drivers have similar implementations
of rvmalloc()/rvfree() et al:
ieee1394/video1394.c
usb/ibmcam.c
usb/ov511.c
media/video/bttv-driver.c
media/video/cpia.c
rvmalloc()/rvfree() are functions that are used to allocate large
amounts of physically non-contiguous kernel virtual memory that will
then be mmap()'ed into a user process.
I just got done writing a driver that needed rvmalloc() in order to do
chip level simulation. Yank and put to the rescue.
Whats the story behind rvmalloc() et al? From what I could tell,
about a year ago there were some patches to move rvmalloc() into
vmalloc() as a blessed feature of the kernel. But it looks to
me like these patches didn't "take".
Is there some other way of doing this now? If so, does somebody
need to go into these drivers and patch them for the blessed way?
If not, is there some plan in place to bless these functions and
remvoe the code duplication?
-Rick
--
Rick Richardson [email protected] http://home.mn.rr.com/richardsons/
Twins Cities traffic animations are at http://members.nbci.com/tctraffic/#1
> I note that at least 5 device drivers have similar implementations
> of rvmalloc()/rvfree() et al:
>
> ieee1394/video1394.c
> usb/ibmcam.c
> usb/ov511.c
> media/video/bttv-driver.c
> media/video/cpia.c
>
> rvmalloc()/rvfree() are functions that are used to allocate large
> amounts of physically non-contiguous kernel virtual memory that will
> then be mmap()'ed into a user process.
I had to rewrite rvmalloc and friends in the bttv driver to support the
new pci dynamic mapping interface. This sounds like a good time to clean
up all these multiple definitions.
Anton
On Sat, Feb 17, 2001 at 06:46:34PM +1100, Anton Blanchard wrote:
>
> > I note that at least 5 device drivers have similar implementations
> > of rvmalloc()/rvfree() et al:
> >
> > ieee1394/video1394.c
> > usb/ibmcam.c
> > usb/ov511.c
> > media/video/bttv-driver.c
> > media/video/cpia.c
> >
> > rvmalloc()/rvfree() are functions that are used to allocate large
> > amounts of physically non-contiguous kernel virtual memory that will
> > then be mmap()'ed into a user process.
>
> I had to rewrite rvmalloc and friends in the bttv driver to support the
> new pci dynamic mapping interface. This sounds like a good time to clean
> up all these multiple definitions.
>
> Anton
If you are offering to do this work now, here is a thread worth
reading which includes a patch to start from...
http://www.uwsg.iu.edu/hypermail/linux/kernel/0002.1/0586.html
BTW, Alan Cox sent me the following additional information in a
private email. Might as well get this in the mailing list archives
for posterity so that the terms "rvmalloc" and "kiovecs" actually
appear in the same post. This way, at least, we all know what the
plan for 2.6 should be.
On Tue, Feb 13 2001 at 14:21:50 -0500 (EST), Alan Cox wrote:
> > Whats the story behind rvmalloc() et al? From what I could tell,
> > about a year ago there were some patches to move rvmalloc() into
> > vmalloc() as a blessed feature of the kernel. But it looks to
> > me like these patches didn't "take".
>
> The plan was to move to kiovecs for this but that didnt make 2.4.
>
> > Is there some other way of doing this now? If so, does somebody
> > need to go into these drivers and patch them for the blessed way?
> > If not, is there some plan in place to bless these functions and
> > remove the code duplication?
>
> I have no problem with someone verifying they are duplicates and doing
> that work.
-Rick
--
Rick Richardson [email protected] http://home.mn.rr.com/richardsons/
Twins Cities traffic animations are at http://members.nbci.com/tctraffic/#1
High oil prices encourage drilling and alternative energy research.
> If you are offering to do this work now, here is a thread worth
> reading which includes a patch to start from...
>
> http://www.uwsg.iu.edu/hypermail/linux/kernel/0002.1/0586.html
>
> BTW, Alan Cox sent me the following additional information in a
> private email. Might as well get this in the mailing list archives
> for posterity so that the terms "rvmalloc" and "kiovecs" actually
> appear in the same post. This way, at least, we all know what the
> plan for 2.6 should be.
Thanks for the info.
Since we arent going to put kiovecs in here for 2.4, I'll just add the 2.4
pci DMA fixes so my bttv card will work in my sparc and someone can look at
cleaning it up properly in 2.5.
Anton