fix comment

I left the previous name for the kern_poll() to not break third-party modules

fixed

Thank you! Ok from me, also, my local repo with this change successfully tinderboxed

export both methods

make kern_poll private, kern_poll_ufds - public
use kern_poll_ufds in freebsd32, linux

Got Roman's ok.

In D30677#689333, @emaste wrote:

Looks like this code first arrived in R10:e16fe1c7304da / D1092

In D30677#689200, @kib wrote:

I am fine with this. It seems rdivacky is not on phab. Did you mailed him about this change?

In D30677#689200, @kib wrote:

I am fine with this. It seems rdivacky is not on phab. Did you mailed him about this change?

In D30597#688997, @emaste wrote:

What error does kern_copy_file_range return if passed pipes

In D30597#687282, @pitwuu_gmail.com wrote:

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

It passes?

In D30597#687217, @emaste wrote:

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

make it more readable

In D30482#684754, @emaste wrote:

Seems reasonable, out of curiosity what prompted taking this on? (I.e., did you discover an issue with the current version?)

sure, rename moduledata name and module name to 'linux_common' and retire 'linuxcommon' line.

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

rename module to linuxcommon

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

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?

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.

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

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