[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <9561.1176209728@redhat.com>
Date: Tue, 10 Apr 2007 13:55:28 +0100
From: David Howells <dhowells@...hat.com>
To: Robin Getz <rgetz@...ckfin.uclinux.org>
Cc: bryan.wu@...log.com, "Alan Cox" <alan@...rguk.ukuu.org.uk>,
waltje@...lt.nl.mugnet.org, "Aubrey Li" <aubreylee@...il.com>,
netdev@...r.kernel.org, "Andrew Morton" <akpm@...l.org>,
"Linux Kernel" <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH] CONFIG_PACKET_MMAP should depend on MMU
Robin Getz <rgetz@...ckfin.uclinux.org> wrote:
> David - I know you have been reworking the noMMU vma handling - is there a
> solution to vm_insert_page?
The reason vm_insert_page() is being called, I imagine, is because
packet_mmap() has to insert mappings to an already existing buffer. All it
does is munge the PTEs in that virtual region to point to the buffer.
As long as the buffer is completely contiguous (which I don't know for
certain), then this function can be trivially reduced in NOMMU-mode to
something that just returns the address of the requested part of the buffer.
No remapping would be required.
However... If the buffer is *not* completely contiguous, then you can still
perform mmaps of it - but only where the desired part _is_ contiguous.
Alternatively, you can arrange for the buffer to be completely contiguous
upfront.
Looking at alloc_pg_vec() in af_packet.c, I will place my bets on the latter
case. I don't know that this is a problem; it depends on how things work, and
that I don't know offhand. If someone can give me a simple test program, I
would be able to evaluate it better.
David
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists