почему системный вызов open () поддерживается в некоторых системах Linux, а не в других?

Question

Я встраиваю системные вызовы.Да, я понимаю, что это проблематично, но у меня есть веская причина.Я значительно отследил свою ошибку и просто спрашиваю, почему __NR_open исчез в этой системе arm64 Arch Linux?

5.0.1-1-ARCH # 1 SMPВс 10 марта 15:08:34 MDT 2019 aarch64 GNU / Linux

Опять же, мой код содержит системные вызовы.Этот метод встраивания работает в другой X86_64 системе, и в действительности встраивание mmap () работает в этой системе.Однако, встраивание open () в этом arm64 Arch Linux завершилось неудачно с EFAULT .

Во-первых, __ NR_open даже не выследил мою ошибкуопределяется в этой среде сборки.Во-вторых, обычные open () вызывает open64 () , которая выполняет инструкцию svc с x8, установленным в # 56, __ NR_openat .В-третьих, __NR_open обычно определяется как 5, и это число было переназначено на __NR_setxattr .Это объясняет, что EFAULT .

По существу, open () преобразуется в openat () в пользовательской библиотеке в этой системе и в __NR_open системный вызов полностью исчез, перешел в новый системный вызов.Что я не понимаю, так это то, что __NR_open определено в каноническом источнике для arm64, но не в этой системе arm64 Arch Linux.

Моя ошибка исправлена ​​просто: inline openat () вместо.Но мой вопрос: почему это было удалено и почему это не считается сломанным из Linux POV?Я думаю о Линусе, который говорит: «1051 * МЫ НЕ ПЕРЕРЫВАЕМ ПОЛЬЗОВАТЕЛЬСКОЕ ПРОСТРАНСТВО!» и я не думаю об этом из POSIX POV.Действительно, Интерфейс программирования Linux не охватывает это удаление, по крайней мере, явно.

Answer 1

Файл, который вы просматриваете, arch/arm64/include/asm/unistd32.h, является определениями системных вызовов для режима сжатия arm32.

Определения системных вызовов для нативного aarch64 взяты из общей таблицы системных вызовов include /uapi / asm-generic / unistd.h , который, как вы видите, не определяет __NR_open.Системный вызов не был удален - он никогда не существовал в aarch64.

Причина, по которой __NR_open не определена в общей таблице, заключается в том, что системный вызов openat(2) был введен позже иэто строгий расширенный набор функций _NR_open, поэтому нет смысла в новых портах архитектуры (созданных после введения openat(2)), обеспечивающих этот системный вызов - это избыточно.Функция POSIX open() предоставляется библиотекой C пользовательского пространства, вызывая системный вызов openat(2).

Порты старой архитектуры, которые существовали до openat(2) - например, x86 и arm32 - должны продолжать включатьopen(2), поскольку старые программы / двоичные файлы библиотеки, безусловно, существуют для тех архитектур, которые вызывают системный вызов open(2).Эта проблема не распространяется на порт новой архитектуры - гарантия «взлома пространства пользователей» заключается в том, что если он работал вчера, он будет работать сегодня, но он не говорит, что если он работал на существующей архитектуре, он может быть перекомпилирован и работать над некоторыми новымиархитектура.

Answer 2

Почему системный вызов open () поддерживается в некоторых системах Linux, а не в других?

Теперь технический ответ прост:

Потому что кто-то так написал.

Но мой вопрос: почему это было удалено и почему это не считается сломанным из Linux POV?

Это не технический вопрос, а философский.

Что мешает кому-либо разветвлять ядро ​​Linux и вносить в него произвольные изменения?
Прошло много времени с тех пор, как я прочитал GNU GPL, но я не помню никаких ограничений такого рода.
И, возможно, нарушение совместимости системного вызова ABI считается нарушенным от Linux POV, но, насколько мне известно, такие взгляды не имеют эффективной власти (юридической или физической) над какой-либо третьей стороной.

Спросите любого, кто отправлял эту вилку AArch64 для Linux, которую вы используете, и, возможно, имеющиеся у вас силы помогут вам осознать причины своего выбора.