Re: CVS commit: src/sys/rump/net/lib/libshmif

[Antti Kantee <pooka%cs.hut.fi@localhost>]

On Fri Mar 11 2011 at 20:37:47 +0300, Alexander Nasonov wrote:
> 11.03.2011, 12:26, "Antti Kantee" <pooka%netbsd.org@localhost>:
> > Log Message:
> > Don't assume rump kernel PAGE_SIZE and host page size are the same.
> 
> Why can they be different? I asked myself this question when I was writing

For example on SPARC page size depends on the model of hardware you're
running on instead of being a compile-time constant (unless you configure
your kernel only for a specific model).

Now, since the rump kernel does not manage memory in the same sense as a
"regular" kernel does, PAGE_SIZE is totally arbitrary.  It's just some
unit of granularity for calling the host's malloc() and remains constant
throughout the life cycle of the kernel instance.  It might as well be
defined to be 32k or 1k on all archs, but that means waging war on the
arch's headers, so it's just easier to play along with whatever we get.

In the shmif initialization routine we are trying to fault in all of the
*host's* pages for the bus file.  We could add a rumpuser_getpagesize(),
but since it makes really no difference if we do 512b or pagesize
increments, at least the shmif case doesn't justify adding it.

The commit didn't fix any bugs, but it's just "more correct" than going
in PAGE_SIZE pieces.

> a tests for kern/44310: write to /dev/bpf truncates size_t to int.
> In the end, I just used sysconf(_SC_PAGE_SIZE). If rump_sysconf doesn't
> exist, should it be added?

Since you are calling mmap() on the host, you want to use host's page size
(although, i guess, technically it doesn't matter since you can't map less
than one page of memory anyway).  Technically you should be using the rump
kernel's IOV_MAX, though, since you are passing that to rump_sys_writev().

-- 
älä karot toivorikkauttas, kyl rätei ja lumpui piisaa