
Комментарии 2
Когда я начинал ARM64-версию, ожидал, что две реализации довольно быстро разойдутся. На практике алгоритм остался практически тем же.
А с чего им расходиться-то, если сделать нужно принципиально одно и то же? Даже в, казалось бы, сильно завязанных на конкретные архитектурные особенности вещи вроде управления памятью на большинстве архитектур разница будет весьма невелика (она вся будет в деталях, но не в принципах: скажем, размер страницы виртуальной памяти может различаться, как различаются и количество уровней таблиц переадресации, и форматы их элементов, но сама идея реализации виртуальной памяти почти везде одинакова -- а соответственно, и алгоритмически она будет практически идентичной).
Реальная разница будет только там, где архитектуры отличаются очень сильно. Например, управление "нижним" вводом-выводом в Линухе для z/Architecture кардинально отличается от всех остальных Линухов -- как раз в силу кардинально иных принципов организации ввода-вывода.
Да, тут я скорее неточно сформулировал - под "разойдутся" имел в виду не сам алгоритм, а низкоуровневую реализацию - без libc ожидал заметно больше arch-specific кода.
Кое-где различия действительно есть: например, на amd64 spawn идёт через fork, на arm64 - через clone(SIGCHLD, ...), плюс разные syscall ABI и обвязка. Но сама state machine - signalfd/epoll, reaping по SIGCHLD, forwarding в PGID, grace timer и restart - в итоге осталась почти один в один.
Как я написал PID 1 для контейнеров на чистом ассемблере: x86-64 и ARM64