Abandon it due to existing patch: D28892

I've found that I have reimplemented this patch by myself (due to lack of internet access):
https://reviews.freebsd.org/D30609

Thanks, Lutz!

LGTM

Thank you, @kevans! fixed.

Fix regression found thanks to tests:

• "jail -r jailname" returned error: jail not found.

Add basic jail tests:

• create/stop/list/restart jails
• create/list nested jail
• execute commands prestart and prestop

Fix SEGFAULT on uninitialized jails_byname.

Generally looks good. Please fix easy remarks.

I prefer to deprecate chips / sub-arch, but not removal. Honestly approach with "unimplementable" atomic_64_swap looks too aggressive.
I and @yamori813_yahoo.co.jp have boards with mips4k SoCs and to be honest such chips do their job well.
Another point: I saw plenty of emails with information that 8Mb is very slow. If it looks small for certain group of people, it doesn't mean that it's small in wide audience. I see that firmware with kernel, modules, 20Mb of uncompressed UFS/CD9660 filesystem is powerful to handle plenty of tasks: routing, monitoring of sensors, graphical output to LCD, keyboard/IR control and so on.

OK except style(9) issues.

Thank you for submission!
Phabricator highlights style(9) issues like spacing/tabs, so it's easy to fix it.

Thank you for review, @mat !
Patch has been corrected according to comment. :) Hope it's OK now.

Many thanks for the patch!

@jhb, many thanks for review!

Small cosmetic changes are required.
But I don't get idea why this marker lookup can't be done by flash_slicer code.
Could you please clarify benefit?

@sgalabov , @adrian , could you please look at?

MIPS is fine:

See D13378

changes:

• move check to vm_phys_alloc_freelist_pages
• assert input parameter freelist instead of uninitialized flind

Cosmetic change: increase MIPS_MAX_TCB_SIZE from 0x20 to 0x1000

In D13134#274207, @meloun-miracle-cz wrote:

with full respect, I don’t think that this is right way. Moreover, I think that you papering over real problem there.
With this patch, what’s happen if someone requests any higher alignment (that actual 16) for TLS data? Or, can patched kernel run the old init (pre r324938)?

After day of digging, I’m still not sure which TLS model mips uses. Mainly which value is expected to be returned by tls_get_tp() function.
It’s clear that mips doesn’t follow Variant I of TLS standard (which require TP pointing to TCB), but it takes relaxed model of this. Something like
“The "thread pointer register" points to some fixed offset from the beginning of the TLS segment. This offset varies by arch“.

If is this true, then my change in libc/gen/tls.h has been significantly incomplete and the arch specific bits need to be implemented.

I don't touch "Summary" because original patch is still good IMHO, but it breaks ABI.
This revision of patch is only kernel change and doesn't break ABI, i.e. buildkernel/installkernel is enough.

On kernel side, we calculate TLS size (td->td_md.md_tls_tcb_offset) in several places used by static & dynamic at same time. So if we roundup2 it, /sbin/init works, but /bin/sh fails.
As of now, I suppose that current fix is the only quick solution :\

In D13134#273128, @brooks wrote:

Is this needed at all after rS325364? We should now be respecting the alignment of the PT_TLS section. If the PT_TLS section isn't correctly aligned then fixing that is the right answer rather than trashing the ABI.

In D13134#273081, @brooks wrote:

Why not just nuke TLS_TCB_SIZE32?

Few cosmetic style issues...