public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Rick Richardson <rickr@mn.rr.com>
To: Anton Blanchard <anton@linuxcare.com.au>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Whats the rvmalloc() story?
Date: Sat, 17 Feb 2001 02:49:48 -0600	[thread overview]
Message-ID: <20010217024948.A1726@mn.rr.com> (raw)
In-Reply-To: <20010210220808.A18488@mn.rr.com> <20010217184633.A2484@linuxcare.com>
In-Reply-To: <20010217184633.A2484@linuxcare.com>; from anton@linuxcare.com.au on Sat, Feb 17, 2001 at 06:46:34PM +1100

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  rickr@mn.rr.com      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.

  reply	other threads:[~2001-02-17  8:50 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2001-02-11  4:08 Whats the rvmalloc() story? Rick Richardson
2001-02-17  7:46 ` Anton Blanchard
2001-02-17  8:49   ` Rick Richardson [this message]
2001-02-17  9:01     ` Anton Blanchard

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20010217024948.A1726@mn.rr.com \
    --to=rickr@mn.rr.com \
    --cc=anton@linuxcare.com.au \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox