One more fix from Allan.

In D20324#450030, @cem wrote:

In D20324#450028, @trasz wrote:

But I've added the justification (explanation of what's the point of ARB, from the consumer point of view) to the man page already. What else is needed?

Are you referring to the single sentence, "[ARB trees] are useful, e.g., when the tree needs to be [transferred] between userspace and kernel", or am I missing the justification? If I am missing the complete justification, please point me at the part of the text that justifies the design. I am looking for considerably better justification than that single sentence.

Update the example.

Remove some cruft.

In D20720#452395, @kib wrote:

In D20720#452326, @trasz wrote:

In D20720#452276, @kib wrote:

In D20720#452264, @trasz wrote:

Well, yes, that’s precisely what it’s intended to do.

It would be even fine if we knew the side effects in advance. I can only repeat, such change should be accompanied by the analysis of effects on other ABIs.

Okay, but what do you mean by that? Apart from what I've done, which is looking at various binaries in FreeBSD, both base and some packages, to verify they are all properly branded?

What you did is just a way to start examine the change and see that it does not break things big outright.
What is needed is understanding how does the change affects selection of the ABI for binary, i.e. explanation which binaries suddenly start being classified for different brand.
That said, we already have sysctl kern.elf{32,64}.fallback_brand and brandelf(8).

Move sources to GitHub, add __FreeBSD_version check.

Update to the new Q_INI(3) syntax; no functional changes.

In D20116#449151, @cem wrote:

In D20116#448990, @trasz wrote:

In D20116#448878, @cem wrote:

I think there are open questions around rounding behavior and making the extensive macros into functions.

The problem with functions is that in many places it uses Q_TC() (which boils down to __typeof()), or macros that expand to Q_TC(). I guess I could try to rework the ones which don't, but that would look inconsistent.

Is it really useful to have any of these operate on anything smaller than a machine word? I think you could basically do all the math on unsigned long (and perhaps uint64_t for 32-bit arch) in functions and just use macros for thin shims that convert word-sized results to the magical smaller width types. Functions are really a lot better than macros to debug and analyze so even if there is a little pain over the current macro approach, I think it is sometimes worth it.

Merge upstream change from lstewart@:

In D20720#452276, @kib wrote:

In D20720#452264, @trasz wrote:

Well, yes, that’s precisely what it’s intended to do.

It would be even fine if we knew the side effects in advance. I can only repeat, such change should be accompanied by the analysis of effects on other ABIs.

(And if you're feeling adventurous, the linux-ltp port contains mprotect tests; you might want to check those as well.)

Looks good. One thing you might want to check, if you have time, is that whether we should just ignore unknown flags? I seem to remember (although I might well be completely confused here) that Linux mmap used to ignore unknown bits; does linux mremap perhaps do the same?

Well, yes, that’s precisely what it’s intended to do.

Which other ABIs?

Merge upstream change from lstewart@:

Anyone?

And, FWIW, glibc doesn't seem to have any kind of fanotify fallback.

Ping? Does the patch look ok?

In D20757#451582, @emaste wrote:

I see the following after 2.6.32 and up to and including 3.2, with uninteresting ports (e.g. m68k) excluded:

recvmmsg(2)                2.6.33
prlimit64(2)               2.6.36

Fixes from sef@ and allanjude@.

Fix typo.

Fix use of pointers as booleans, use ptrdiff_t, and add brief explanation
of rounding (or lack thereof).

In D20324#449149, @cem wrote:

In D20324#449008, @trasz wrote:

So... is there anything else left to do here?

A design justification is still missing. Pointing to another proposed patch with fundamentally the same unanswered design questions as a potential consumer isn't in itself a good justification to take this.

So... is there anything else left to do here?

Add ARB_ALLOCSIZE().

In D20757#448836, @emaste wrote:

Do we have a list of syscalls/interfaces by kernel version anywhere?

In D20687#448848, @emaste wrote:

Also is it the case that /bin/echo 1 1 1 1 1... consistently fails with some number of 1s and runs successfully with other cases? Like 1 1 1 works, 1 1 1 1 fails, 1 1 1 1 1 works?

In D20687#448843, @emaste wrote:

Do you have more details about working/non-working versions? I.e., what glibc version works?

In D20116#448878, @cem wrote:

In D20116#448783, @trasz wrote:

So... is there anything else left for me to do here before this can get committed?

I think there are open questions around rounding behavior and making the extensive macros into functions.

So... is there anything else left for me to do here before this can get committed?

In D20720#448424, @greg_unrelenting.technology wrote:

In D20720#448402, @trasz wrote:

In D20720#448101, @greg_unrelenting.technology wrote:

Many many many Linux binaries are ELFOSABI_NONE.
The Elf64_Brandinfo definitions directly above the added lines allow executables with ELFOSABI_NONE to run when interp_path matches. You can see one was added for musl libc, before that one was added, Alpine Linux did not work.
But that's for normal executables.

But the musl entry still says ELFOSABI_LINUX, doesn't it?

Yes, that doesn't mean it won't match with NONE.
https://github.com/freebsd/freebsd/blob/fc870a6df90c3876ec348720e21e74beb8b70d92/sys/kern/imgact_elf.c#L378-L395 "Lacking a known brand, search for a recognized interpreter"

It was compared under VMWare Fusion - with the change the value matches what the actual CentOS reports.

In D20720#448101, @greg_unrelenting.technology wrote:

Many many many Linux binaries are ELFOSABI_NONE.
The Elf64_Brandinfo definitions directly above the added lines allow executables with ELFOSABI_NONE to run when interp_path matches. You can see one was added for musl libc, before that one was added, Alpine Linux did not work.
But that's for normal executables.

In D20720#448098, @kib wrote:

In D20720#448095, @trasz wrote:

Without this commit, Linux ldd is broken - it errors out due to not being able to exec rtld. No idea why rtld is like this, but, well, it is - both in Centos and Ubuntu.
It probably also fixed Android binaries; I hadn’t tested it this time.

So the issue is that shared objects do not specify ABI ? Does it mean that with the change, direct execution mode for our rtld (and then our ldd) is either broken or only works by chance ?

Without this commit, Linux ldd is broken - it errors out due to not being able to exec rtld. No idea why rtld is like this, but, well, it is - both in Centos and Ubuntu.

Hm, true. Add a sysctl perhaps, to turn it on and off?

Meh.

FWIW, trying to run apt-get autoremove results in:

Ping?