In D19911#440721, @jrm wrote:

I'm not an Erlang user, so I can only be a general extra set of eyes here. I can do also do poudreire testing. Is there anything specific I can do to help test?

Update to 3.7.15.

Oops, I somehow sent that early. I was going to say...

Hello Jimmy,

Update to 1.8.2.

Update to the latest 21.x version plus minor fixes.

I only proposed getting rid of a mips32 SMP kernel. There's mips32r6 instructions that could be used to implement 64-bit atomics, so I stayed my hand.
I've not looked closely enough at the rest of this patch to click 'OK' but I have no objections.

Fix a keyword error in the conf file.

In D20380#440650, @kib wrote:

In D20380#440642, @alc wrote:

In D20380#440609, @kib wrote:

I am not sure why do check that KERNend != round_2mpage() before rounding, IMO it simply less lines to not do that.

Are you asking about this snippet?

if (*firstaddr < round_2mpage(KERNend))
        *firstaddr = round_2mpage(KERNend);

Yes.

Change patch so that it affects arm6 and arm7, but not arm4 or arm5.

I ran all of the devfs tests I have.
I added a new parallel mkdir() and rmdir() test with VM pressure.
No problems seen.

In D17512#439294, @jhb wrote:

I still don't understand why i386 is special in this regard. Surely i386 isn't the only architecture to ever use this type of relocation?

In D20412#440673, @dougm wrote:

No testing on an actual arm machine has been performed.

No testing on an actual arm machine has been performed.

__clzdi2() and other functions are indeed libgcc symbols implementing the builtins, so at least gcc cannot properly inline the operation.

In D18593#440643, @jah wrote:

To answer my own question: no, we can't repurpose entry 0. We wire it down in switch.S to guarantee we won't take TLB faults on access to the kernel stack. Makes sense, esp. if we don't have something like a boot stack or exception stack to fall back on.

In D20412#440654, @kib wrote:

So why not do this for all architectures ? Is the problem that old gcc on ppc/sparc64/mips does not support __builtins required ?

In D20411#440660, @kib wrote:

In D20411#440658, @tijl wrote:

In D20411#440580, @mjg wrote:

I think arbitrary mkdir/rmdir is a can of worms, perfectly avoidable for the stated purpose.

Arbitrary symlinks are already supported. Why would mkdir be any different?

In D20411#440658, @tijl wrote:

In D20411#440580, @mjg wrote:

I think arbitrary mkdir/rmdir is a can of worms, perfectly avoidable for the stated purpose.

Arbitrary symlinks are already supported. Why would mkdir be any different?

In D20411#440580, @mjg wrote:

I think arbitrary mkdir/rmdir is a can of worms, perfectly avoidable for the stated purpose.

Arbitrary symlinks are already supported. Why would mkdir be any different?

So why not do this for all architectures ? Is the problem that old gcc on ppc/sparc64/mips does not support __builtins required ?

In D20266#440649, @pho wrote:

I ran tests on D20266.57868.diff for 24 hours without seeing any problems.

In D20380#440642, @alc wrote:

In D20380#440609, @kib wrote:

I am not sure why do check that KERNend != round_2mpage() before rounding, IMO it simply less lines to not do that.

Are you asking about this snippet?

if (*firstaddr < round_2mpage(KERNend))
        *firstaddr = round_2mpage(KERNend);