In D30332#691205, @dchagin wrote:

Im don't understand what do you mean, I mean that musl it's a separate brand, see Elf_Brandinfo and linux_sysvec.c,
and only for musl brand we should change cmp_requeue, for glibc brand cmp_requeue should return EINVAL

In D30457#689929, @trasz wrote:

Nice! Regarding GET_SYSCALL_INFO - this reminded me that I also had a patch for this, https://reviews.freebsd.org/D28212; I guess we should try merging our changes.

There's some activity right now regarding Linuxulator signal delivery, https://reviews.freebsd.org/D30675; I wonder if it's related?

In D30597#687263, @dchagin wrote:

In D30597#687217, @emaste wrote:

Does this have test coverage via e.g. LTP?

yes, also linux source at tools/testing/selftests/splice

Cool. Thanks for working on it. Obviously this is an "emulation" way of implementing splice(2) and not the real thing, but I like this. Do you happen to know which software requires the splice(2) call for its correct operation?

In D30457#687072, @trasz wrote:

This looks really interesting, thanks for working on it!

Which version of strace(1) are you testing with? I kind of hoped this would fix the one from Ubuntu Focal (the one from Bionic already worked fine), but this doesn't seem to be the case.

Tested. It works and is good to go. Intel 7260.
One nit: we have files from iwmbt-firmware located @ /usr/local/share/iwmbt-firmware/
and this present utility looks in /usr/share/firmware/intel.
Maybe we could make it look sequentially in one, then the other. ?

Ah yes I forgot. There's a second point of failure in our current ptrace. Currently all signals emit an event for ptrace to consume, which is not the behaviour on Linux, where all signals emit a signal except SIGKILL which behaves normally.
From the man page:

In D30378#684088, @dchagin wrote:

we have so many such unfinished things, like arm linuxulator, splice sys call....

Yes, about splice, I was thinking we could just use a regular copy and be done with it. It wouldn't be that hard to implement, I can possibly look at it.

some time ago I wrote splice emulation via dofileread/dofilewrite ) but I abandoned it because I think we need a native splice() and tee() implementation. feel free to as arch@ about it:)

In D30378#684088, @dchagin wrote:

we have so many such unfinished things, like arm linuxulator, splice sys call....

Yes, about splice, I was thinking we could just use a regular copy and be done with it. It wouldn't be that hard to implement, I can possibly look at it.

some time ago I wrote splice emulation via dofileread/dofilewrite ) but I abandoned it because I think we need a native splice() and tee() implementation. feel free to as arch@ about it:)

The most pressing issue is the incomplete pthread support notably with FUTEX_LOCK_PI and FUTEX_UNLOCK_PI and friends.

https://wiki.freebsd.org/Linuxulator#Roadmap, pi is not the key, we have so many important holes

In D30378#684071, @dchagin wrote:

In D30378#684069, @pitwuu_gmail.com wrote:

In D30378#684068, @emaste wrote:

Encountered in the crash handler of 'kodi'. Kodi still crashes, but at least the crash handler doesn't seem to crash anymore.

IMO this sort of thing is sufficient reason to have this linprocfs entry. What do you think about extending it slightly, at least translating FreeBSD's default %N.core to the Linux equivalent (%e.core I guess?)

we have so many such unfinished things, like arm linuxulator, splice sys call....

In D30333#683079, @arrowd wrote:

lots of output

In D30378#684068, @emaste wrote:

Encountered in the crash handler of 'kodi'. Kodi still crashes, but at least the crash handler doesn't seem to crash anymore.

IMO this sort of thing is sufficient reason to have this linprocfs entry. What do you think about extending it slightly, at least translating FreeBSD's default %N.core to the Linux equivalent (%e.core I guess?)

In D30378#684066, @emaste wrote:

Is there a way to config git to do that by default? It's annoying to do every time.

I'm not sure, although I also suspect you don't want it when generating a patch for your own review, not for upload to Phabricator. There is a tool in the tree, tools/tools/git/git-arc, which can take care of submitting phab reviews for you.

In D30378#683157, @emaste wrote:

For future uploads please include full context by using e.g. git show -U99999 <hash> - see https://wiki.freebsd.org/Phabricator for details

Give us the output of 'pciconf -lv' please.

In D30333#681628, @emaste wrote:

Please confirm Philippe Michaud-Boudreault <pitwuu@gmail.com> as the correct author info for Git.