Yeah, sorry about the confusion.

Hi,
sorry, I somehow assumed you have a commit bit. This is not the case, right? So @dumbbell , @emaste, or I need to commit your changes?

@bz If you have some time, can you let me know if there are any additional changes I should make?

Fixed formatting, incremented to correct value, fixed description, added test plan.

Merged in c90c46ea239f

shipit!

In D58753#1350996, @adrian wrote:

In D58753#1350991, @nick_spun.io wrote:

In D58753#1350915, @adrian wrote:

(a) what was this for again
(b) .. why can't we have a freebsd dmabuf implementation that we can use, and linuxkpi plugs into that?

(a) lol this was for Cyberpunk 2077 in "Proton-under-Linuxulator"
(b) You mean something in base? I definitely don't see a reason _not_ to

ok, for maximum lols, please add something like this in your commit message

Locally tested:

• cyberpunk 2077 running in proton in linuxulator (still working on audio though!)

and (b) yeah, let's find dumbbell when they're active on IRC and go figure out what's required to just make a native dmabuf implementation for freebsd. Surely it's not going to move THAT quickly, and it'll help us in our desire for native drivers for stuff.

I didn't work on the implementation of dma-buf for FreeBSD. We have this BSD-licensed implementation in drm-kmod right now and we can surely move that to base. I find it receives changes infrequently in Linux, so hopefully, that shouldn't be something that slows down or interferes with making a given version of drm-kmod compatible with multiple versions of FreeBSD.

In D58753#1350991, @nick_spun.io wrote:

In D58753#1350915, @adrian wrote:

(a) what was this for again
(b) .. why can't we have a freebsd dmabuf implementation that we can use, and linuxkpi plugs into that?

(a) lol this was for Cyberpunk 2077 in "Proton-under-Linuxulator"
(b) You mean something in base? I definitely don't see a reason _not_ to

In D58753#1350915, @adrian wrote:

(a) what was this for again
(b) .. why can't we have a freebsd dmabuf implementation that we can use, and linuxkpi plugs into that?

well if dumbbell says ok :-)

(a) what was this for again
(b) .. why can't we have a freebsd dmabuf implementation that we can use, and linuxkpi plugs into that?

In D58228#1349195, @bz wrote:

What's the KBI impact of this? Does it need a __FreeBSD_version bump then? Would it make sense to add it to the end?

Just bumping if anyone has time

Just bumping

What's the KBI impact of this? Does it need a __FreeBSD_version bump then? Would it make sense to add it to the end?

@bz Let me know if you've got any time to look over these changes. Thank you!

That looks fine to me, at least.

For reference, moved to D56251

I did not originally include all the syscall.master files' changes, they've now been included, @Nimish Jain also helped point out that I could simplify the function quite a bit.

create a pull request on github...

This is created from diff file. I just created another one followed the instructions with arc command

Remove additional unexpected empty line change

This is unrelated to LinuxKPI. Remove the reviewer.