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

Я встраиваю системные вызовы. Да, я понимаю, что это проблематично, но у меня есть веская причина. Я значительно выследил свою ошибку, и я просто спрашиваю, почему __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.

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


arm64 linux-kernel archlinux-arm
person Olsonist    schedule 28.03.2019    source источник

Ответы (1)


arrow_upward
7
arrow_downward

Файл, который вы просматриваете, 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). Эта проблема не касается порта новой архитектуры - гарантия «нарушения пользовательского пространства» заключается в том, что если он работал вчера, он будет работать сегодня, но это не говорит о том, что если он работал на существующей архитектуре, он может быть перекомпилирован и работать на какой-то новой. архитектура.

person caf    schedule 28.03.2019