Source-Changes-D archive

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]

Re: MAX_PAGE_SIZE for m68k (Re: CVS commit: src/sys/arch/arm/include/arm32)



In article <20200113163830.E7A6317FDC7%rebar.astron.com@localhost>,
Christos Zoulas <christos%zoulas.com@localhost> wrote:
>| 
>| Probably this is the same reason of recent arm build failures:
>|  https://releng.netbsd.org/builds/HEAD/202001130720Z/
>|  https://releng.netbsd.org/builds/HEAD/202001130720Z/evbarm-earm.build.failed
>| ---
>| /tmp/genassym.Lq8h9d/assym.c:57:1: error: asm operand 0 probably
>doesn't match constraints [-Werror]
>|  __asm("XYZZY VM_MIN_ADDRESS %0" : : "n" (VM_MIN_ADDRESS));
>|  ^~~~~
>| /tmp/genassym.Lq8h9d/assym.c:58:1: error: asm operand 0 probably
>doesn't match constraints [-Werror]
>|  __asm("XYZZY VM_MAXUSER_ADDRESS %0" : : "n" (VM_MAXUSER_ADDRESS));
>|  ^~~~~
>| /tmp/genassym.Lq8h9d/assym.c:97:1: error: asm operand 0 probably
>doesn't match constraints [-Werror]
>|  __asm("XYZZY PAGE_MASK %0" : : "n" (PAGE_MASK));
>|  ^~~~~
>| /tmp/genassym.Lq8h9d/assym.c:98:1: error: asm operand 0 probably
>doesn't match constraints [-Werror]
>|  __asm("XYZZY PAGE_SIZE %0" : : "n" (PAGE_SIZE));
>|  ^~~~~
>| ---
>| 
>| Should we prepare independent constant for
>| "possible pagesize value among different MACHINE with the same MACHINE_ARCH"
>| for jemalloc(3)?
>
>Ouch, this hurts. Sure, perhaps MALLOC_PAGE_SIZE?

Talking to myself:

The arm PAGE_SIZE_{MIN,MAX} should go away after nick eliminates the
need for the 8K pages. This leaves us with m68k to deal with...
Do modules work on m68k? Should modules be shared between kernels with
different page sizes? Then perhaps we don't need a new constant?

christos



Home | Main Index | Thread Index | Old Index