linux: add dma-buf and sync_file ioctl handlers

[nick_spun.io]

Summary

drm-kmod already implements the dma-buf and sync_file ioctls, but
linux_ioctl.c had no handler group for the 'b' and '>' magic bytes, so
the requests never reached it and returned EINVAL from
linux_ioctl_fallback(). Route the commands drm-kmod services to
sys_ioctl(), translating the direction bits with SETDIR(); everything
else still falls through to the fallback and keeps getting named in
dmesg.

Signed-off-by: Nick Price <[e-mail]>

[adrian]

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

[adrian]

well if dumbbell says ok :-)

[nick_spun.io]

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

[adrian]

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.

[dumbbell]

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.