>>210466
То что имея возможность править код ядра все это в принципе решаемо очевидно, но это примерно как считать что любой софт можно написать на ассемблере.
Железо значительно ушло вперёд, и уже нельзя, например, считать что 0х378 всегда попадет на параллельный порт, с одной стороны, с другой, код должен поддаваться переиспользованию.
Времена тупого роста мегагерц и гигабайт безлатентной памяти прошли, бизнес-логика и вычисления требуют противоположных подходов, и настоящее и ближайшее будущее - это неоднородный доступ к памяти, зоопарки специализированных шин, аппаратные модули и целые сопроцессоры под специализированные задачи (видео, нейросети, роутинг пакетов...).
Все это, во-первых, стоит денег за готовые IP-блоки (микроэлектроника тоже не стоит на месте и описывается все более высокоуровневыми языками и библиотеками, с разделением фирм на писателей библиотек базовых блоков того что может делать фаб, абстрактных кирпичиков логических функций, больших блоков вроде процессорных ядер и собственно производите,), во-вторых, занимает площадь кристалла, повышая риск брака и цену, в-третьих, вредит производительности.
В результате фрагментация soc-ов неизбежна, и даже в рамках одного типа запускается одновременно лишь небольшая часть ресурсов, потому что все равно есть узкие места (тепловыделение, пропускная способность внутренних шин, требования по выравниванию и разруливанию доступа к памяти, ограниченное число внешних выводов...). А это значит, что должны быть удобные и быстрые способы конфигурировать работу периферии под конечные задачи, и делаться это должно на стороне ядра, это его задача все это эффективно использовать и абстрагировать от приложений.
