Is it worth us having somewhere something like:

#if defined(LINUXKPI_VERSION) && LINUXKPI_VERSION < 50000
#error LINUXKPI_VERSION < 50000 not supported
#endif

Both sys/ofed/drivers/infiniband/core/ib_uverbs_main.c and sys/dev/pms/freebsd/driver/common/lxencrypt.c seems to use the old access_ok definition.

In D29391#658261, @manu wrote:

Both sys/ofed/drivers/infiniband/core/ib_uverbs_main.c and sys/dev/pms/freebsd/driver/common/lxencrypt.c seems to use the old access_ok definition.

Ah mumble. I misunderstood @hselasky 's "The kernel doesn't use it" then. Sigh. My bad. I wonder if we want to flip the default then or change (update) the consumers?

In D29391#658264, @bz wrote:

In D29391#658261, @manu wrote:

Both sys/ofed/drivers/infiniband/core/ib_uverbs_main.c and sys/dev/pms/freebsd/driver/common/lxencrypt.c seems to use the old access_ok definition.

Ah mumble. I misunderstood @hselasky 's "The kernel doesn't use it" then. Sigh. My bad. I wonder if we want to flip the default then or change (update) the consumers?

The kernel doesn't use LINUXKPI_VERSION, so it have the old definition.

I haven't compile-tested this that I did not foo-bar it again.
But changing the three consumer lines seems straight forward enough.

I'll wait for @hselasky and @rlibby to see if they are okay with it.

In D29391#658362, @rlibby wrote:

LGTM, and I checked $work's tree for other references.

Thanks!

But, did you mean to tag @rstone? I don't think we have any other funky version dependency, but if we do then I think he would know.

I think you touch pms(4) and that's why I had added you.