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

hi, what is the purpose for this? it will be used read only. so what is the program depend on it?

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

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

In D30378#683170, @dchagin wrote:

hi, what is the purpose for this? it will be used read only. so what is the program depend on it?

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

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#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.

I'll check it out, thanks.

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#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?)

I don't know, maybe. I haven't had any luck using core files either on FreeBSD or on the Linuxulator, so I have to plead ignorance in how to use these.
I don't think they are even usable, since the core file is in FreeBSD format that linux gdb can't parse, and confuse the freebsd gdb because it's a linux process/elf.

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....

I don't know, maybe. I haven't had any luck using core files either on FreeBSD or on the Linuxulator, so I have to plead ignorance in how to use these.
I don't think they are even usable, since the core file is in FreeBSD format that linux gdb can't parse, and confuse the freebsd gdb because it's a linux process/elf.

https://reviews.freebsd.org/D30019

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....

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.
The most pressing issue IMO is the incomplete pthread support notably with FUTEX_LOCK_PI and FUTEX_UNLOCK_PI and friends.
I just want things to run without crashing, I don't care if we don't beat speed contests. For FUTEX_LOCK_PI and FUTEX_UNLOCK_PI could we use a regular mutex?
This is offtopic though I suppose.

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

I don't think they are even usable, since the core file is in FreeBSD format that linux gdb can't parse, and confuse the freebsd gdb because it's a linux process/elf.

As @dchagin points out in D30019 we have a change to generate Linux-format coredumps, but anyhow lldb should be able to deal with a Linux ELF binary and FreeBSD ELF coredump.

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

It's literally the second item on that list, for example pulseaudio hard crashes because it's not there. I have started but it's pretty hard, I wonder if anyone can help?

I also have a patch for some improvements to PTRACE but I will open a new ticket.

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:)

Why do we need it? All the BSD's seem to exist without splice() just fine?
I'm interested in the dofileread/dofilewrite emulation way because that'd get support in! Do you still have your work around?

FWIW, splice(2) can be a wrapper around copy_file_range(2). We should also have a fallback from sendfile(2) to splice(2), for when it fails with ENOTSOCK. This is one of the things that break Mono.

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

It's literally the second item on that list, for example pulseaudio hard crashes because it's not there. I have started but it's pretty hard, I wonder if anyone can help?

yes, really hard. I also tried for a very long time ago, but I think there are more urgent tasks like netlink, timehands, vdso

Why do we need it? All the BSD's seem to exist without splice() just fine?

whoops, native - not a freebsd system call, Linuxulator sys call implemented like a native, not a like "tiny wrapper"

I'm interested in the dofileread/dofilewrite emulation way because that'd get support in! Do you still have your work around?

I'll try to search

In D30378#684094, @trasz wrote:

FWIW, splice(2) can be a wrapper around copy_file_range(2). We should also have a fallback from sendfile(2) to splice(2), for when it fails with ENOTSOCK. This is one of the things that break Mono

indeed

we have so many such unfinished things

Indeed, let's avoid adding to the list, then, and make a more complete implementation of this. I was worried that we have many FreeBSD-specific options that don't have a trivial translation, but it's not too bad. In fact FreeBSD has a limited set documented in a comment:

* corefile_open(comm, uid, pid, td, compress, vpp, namep)
* Expand the name described in corefilename, using name, uid, and pid
* and open/create core file.
* corefilename is a printf-like string, with three format specifiers:
*      %N      name of process ("name")
*      %P      process id (pid)
*      %U      user id (uid)
* For example, "%N.core" is the default; they can be disabled completely
* by using "/dev/null", or all core files can be stored in "/cores/%U/%N-%P".
* This is controlled by the sysctl variable kern.corefile (see above).

However there are additional supported ones not included in the comment, but are documented in core.5. Of these all except %I appear to have direct Linux translations. I think handling all but %I would be fine.

FWIW, splice: https://reviews.freebsd.org/D30597