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
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Feed Advanced Search
Advanced Search
Advanced Search
Jun 14 2021
Jun 14 2021
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?
Jun 1 2021
Jun 1 2021
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.
May 30 2021
May 30 2021
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. ?
/* * Every command has its associated event: data must match * what is recorded in the firmware file. Perform that check * now. * * Some commands are mapped to more than one event sequence, * in that case we can drop the non-patch commands, as we * probably don't need them for operation of the card. * */
May 25 2021
May 25 2021
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
May 23 2021
May 23 2021
Give us the output of 'pciconf -lv' please.
May 21 2021
May 21 2021
May 20 2021
May 20 2021
In D30333#681628, @emaste wrote:Please confirm Philippe Michaud-Boudreault <pitwuu@gmail.com> as the correct author info for Git.
May 18 2021
May 18 2021