public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
* commit 68e5e9d734503695915734e50e9427624cf8f3b2 (Re: vfb: make virtual framebuffer mmapable)
@ 2009-10-02 10:19 Jan Beulich
  2009-10-02 12:44 ` Ilya Yanok
  0 siblings, 1 reply; 2+ messages in thread
From: Jan Beulich @ 2009-10-02 10:19 UTC (permalink / raw)
  To: adaplas, ilya.yanok; +Cc: linux-kernel

Is there any particular reason why this change uses vmalloc_32()
rather than simply vmalloc()? I can't see why the underlying physical
address width would matter here in any way...

Thanks, Jan


^ permalink raw reply	[flat|nested] 2+ messages in thread

* Re: commit 68e5e9d734503695915734e50e9427624cf8f3b2 (Re: vfb: make virtual framebuffer mmapable)
  2009-10-02 10:19 commit 68e5e9d734503695915734e50e9427624cf8f3b2 (Re: vfb: make virtual framebuffer mmapable) Jan Beulich
@ 2009-10-02 12:44 ` Ilya Yanok
  0 siblings, 0 replies; 2+ messages in thread
From: Ilya Yanok @ 2009-10-02 12:44 UTC (permalink / raw)
  To: Jan Beulich; +Cc: adaplas, linux-kernel

Hi Jan,

Jan Beulich wrote:
> Is there any particular reason why this change uses vmalloc_32()
> rather than simply vmalloc()?

I don't think so. I wasn't very experienced with kernel programming that
time and just copied code from another driver. Actually I think we don't
really need all this rvmalloc()/rvfree() magic we just need to use
remap_vmalloc_range() instead of remap_pfn_range().

Regards, Ilya.


^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2009-10-02 12:44 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-10-02 10:19 commit 68e5e9d734503695915734e50e9427624cf8f3b2 (Re: vfb: make virtual framebuffer mmapable) Jan Beulich
2009-10-02 12:44 ` Ilya Yanok

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox