fwiw crc16.h is used in (only)
sys/dev/atopcase/atopcase.c
sys/fs/ext2fs/ext2_csum.c

In D60275#1384110, @wulf wrote:

firstly we'd be changing the KBI (I think) on systems where sizeof(unsigned int) != size_t.

crc16() is static inline. It should not have KBI unless maybe exotic cases like -O0 or execution via pointer.

firstly we'd be changing the KBI (I think) on systems where sizeof(unsigned int) != size_t.

It looks all that`s needed is to change crc16() len parameter type from unsigned int to size_t in sys/sys/crc16.h and add #include <sys/crc16.h> line to linux/crc16.h

In D60275#1383168, @wulf wrote:

Created & implemented crc16.h, there are some new functions which I could not find already implemented in the FreeBSD base system

crc16() is implemented in sys/crc16.h
crc16_byte() is not used in drm-kmod and has been removed from Linux after v6.15

It looks all that`s needed is to change crc16() len parameter type from unsigned int to size_t in sys/sys/crc16.h and add #include <sys/crc16.h> line to linux/crc16.h

Created & implemented crc16.h, there are some new functions which I could not find already implemented in the FreeBSD base system

Made this change, running build test right now.

Switched fallback to 0 GHz

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?