some issues with #defines

some issues with #defines

[Justin Cormack]

[-- Attachment #1: Type: text/plain, Size: 347 bytes --]

PAGE_SIZE is defined in include/bits/limits.h but I am not sure it should
be. As far as I can see glibc does not define it at all any more fo
userspace (see man page for getpagesize).

Running into other issues too with includes but suspect they are include
bugs and need to look at them further, was looking at compiling native kvm
tool.

Justin

[-- Attachment #2: Type: text/html, Size: 472 bytes --]

Re: some issues with #defines

[Rich Felker]

On Sat, Dec 01, 2012 at 11:52:19PM +0000, Justin Cormack wrote:
> PAGE_SIZE is defined in include/bits/limits.h but I am not sure it should
> be. As far as I can see glibc does not define it at all any more fo
> userspace (see man page for getpagesize).

I'm aware that glibc does not define it because they consider it
variable. musl considers it constant because increasing it just wastes
large amounts of memory. The OS is still free to use larger hardware
pages transparently when possible; all PAGE_SIZE really represents the
the granularity of mmap.

I've only run into one program which had a problem due to musl
defining PAGE_SIZE; it was using PAGE_SIZE for its own purposes. This
usage is non-portable since POSIX defines PAGE_SIZE. Per POSIX, if
PAGE_SIZE is defined it's a contant, and if it's not defined, it might
be variable, and the application must use sysconf() to query the page
size. Portable applications can always use sysconf() if desired, but
portable applications wanting to be more efficient can conditionally
use PAGE_SIZE directly if it's defined (allowing a lot of compile-time
constant propagation optimizations) and only fallback to the slower
and more bloated runtime calculations on systems that lack the macro.

> Running into other issues too with includes but suspect they are include
> bugs and need to look at them further, was looking at compiling native kvm
> tool.

There are still lots of issues with very-low-level programs that do
hackish trace/debugger/jit type stuff not liking musl's headers. I'm
working on improving the situation in some respects, but I'm not sure
how successful things will be without some help from their side too.

Rich

Re: some issues with #defines

[Justin Cormack]

[-- Attachment #1: Type: text/plain, Size: 2172 bytes --]

On 2 Dec 2012 03:26, "Rich Felker" <dalias@aerifal.cx> wrote:
>
> On Sat, Dec 01, 2012 at 11:52:19PM +0000, Justin Cormack wrote:
> > PAGE_SIZE is defined in include/bits/limits.h but I am not sure it
should
> > be. As far as I can see glibc does not define it at all any more fo
> > userspace (see man page for getpagesize).
>
> I'm aware that glibc does not define it because they consider it
> variable. musl considers it constant because increasing it just wastes
> large amounts of memory. The OS is still free to use larger hardware
> pages transparently when possible; all PAGE_SIZE really represents the
> the granularity of mmap.
>
> I've only run into one program which had a problem due to musl
> defining PAGE_SIZE; it was using PAGE_SIZE for its own purposes. This
> usage is non-portable since POSIX defines PAGE_SIZE. Per POSIX, if
> PAGE_SIZE is defined it's a contant, and if it's not defined, it might
> be variable, and the application must use sysconf() to query the page
> size. Portable applications can always use sysconf() if desired, but
> portable applications wanting to be more efficient can conditionally
> use PAGE_SIZE directly if it's defined (allowing a lot of compile-time
> constant propagation optimizations) and only fallback to the slower
> and more bloated runtime calculations on systems that lack the macro.

Thanks for that. It is including it because it is also including kernel
headers which is always a mess.

> > Running into other issues too with includes but suspect they are include
> > bugs and need to look at them further, was looking at compiling native
kvm
> > tool.
>
> There are still lots of issues with very-low-level programs that do
> hackish trace/debugger/jit type stuff not liking musl's headers. I'm
> working on improving the situation in some respects, but I'm not sure
> how successful things will be without some help from their side too.
>

Yes it is basically defining userspace kernel drivers so liable to be
messy. However it only seems to be a few places so will have a look at
patching it. It gives a way to run KVM without qemu and with much less code
(5k lines) so would be nice to have.

Justin

[-- Attachment #2: Type: text/html, Size: 2614 bytes --]