Комментарии 2
История cKVM_GET_API_VERSION и EINVAL — классика. Сам ловил похожее с ioctl, когда дескриптор не описывал вариативный аргумент. А почему всё-таки FFM, а не JNI? Понятно, что меньше glue-кода, но были моменты, где JNI оказалось бы проще?
Основная мотивация была в том, чтобы новое апи потрогать.
По сути то в JDK, как ты правильно заметил, FFM появился как замена ровно по той причине, что убирает glue код и дает более современный апи, в сравнении с JNI.
Конкретно при работе с ioctl, которая по сути - макрос, было бы действительно проще JNI использовать и тогда чать работы с ABI взял бы на себя C копилятор. А когда работа идет через FFM, то это всё приходится держать в голове и учитывать в Java.
Кстати, если весь ABI состоит только из функций, без всяких макросных выкрутасов, то можно использовать jextract. Это уже дополнение чисто к FFM. Он на основе заголовков .h вытаскивает всю сигнатуру на этапе компиляции. Но к специфичным решениям, типа макросов оно уже не применимо из-за ограничений самой библиотеки.

Linux из Java без JNI: от FFM и /dev/kvm до интерактивной консоли