Новое ядро на старых колёсах

зумерки уже и не знают про ndiswrapper

Как обычно, больше всего понтов - от нубья))

Запусти через ndiswrapper видеодрайвер, например, а я посмотрю на твои потуги.

Можно. Как минимум есть 2 примера.

А именно?

Ну ndiswrapper тебе сказали. И не надо про видюхи. В винде ты тоже видюху не запустишь с дровами у звуковухи. У каждой подсистемы свои особенности.

Второй PalmOS, где они сменили проц и продолжили исполнять старый софт.

Драйвер тупо получает некие команды через его API и пишет что либо в регистры или перемещает биты в памяти. ВСЕ. Можно даже драйвер в qemu запустить. Вопрос в трудоемкости и производительности.

В винде ты тоже видюху не запустишь с дровами у звуковухи

Чиво?

где они сменили проц и продолжили исполнять старый софт

При чём тут проц и прикладной софт?

Наш друг alphex_kaanoken такое удачно реализовывал в одной из собственных ОС.

Ещё более толстый слой говна. Вместо того, чтобы выносить окукливание железа. Прэлэстно

Концептуально – да, это называется rump kernel/anykernel, NetBSD так умеет уже несколько лет. На практике – нет, Linux ещё не научили.

https://research.csiro.au/tsblog/using-rump-kernels-to-run-unmodified-netbsd-drivers-on-sel4/

rump kernel/anykernel

возьмите пачку, любую пачку /ковыряет ножиком упаковку кокса/

Можно, почему нет лол? Что может мешать по твоему вообще? Ну разве что растеры такое никогда не осилят.

Прямо навскидку – помешает другая модель управления памятью и процессорами, если вы не хотите статически выделять память и треды на каждый «драйвер».

Вот книга о том, что помешает, если хотите углубиться в тему: http://www.fixup.fi/misc/rumpkernel-book/rumpkernel-bookv2-20160802.pdf

Решается ж, какая это проблема. А по ссылке форибден.

помешает другая модель управления памятью и процессорами

Я так понимаю, в монолите это принципиально нерешаемо, только в микроядре?

зумерки уже и не знают про Video4BSD и L4Linux

Не, с моей колокольни кажется что это чинится умением «драйвера» агрессивно хотплагать память и процессоры обратно в хост, но я не эксперт.

Мне очень хотелось бы, однако, посмотреть как псевдонимус сверху проталкивает эти патчи в mainline.

Возможно ли теоретически создать некий интерфейс или прослойку между написанным с нуля ядром и линуксовыми дровами?

Да, конечно. Модуля ядра - практически обычные программы, только взаимодействуют с API ядра. Реализуете нужное подмножество API ядра и модуль заработает.

Другое дело, что этот API не стабилен и периодически переделывается. В Windows, например, такой API держат стабильным в течении большего времени, вроде номерных версий системы или сервис-паков. По этому проект ReactOS более или менее способен использовать драйверы Windows.

проект ReactOS более или менее способен использовать драйверы Windows

Интересный пример, но насколько я знаю, РеактОСь пытается воссоздать ядро Винды, а не предлагает что-то принципиально иное.

Возможно ли

не для всех. где-то сложно, а где-то тормозить будет.

чем оно будет лучше линукса

Да, но это ведь по любому независимая реализация. Т.е. фактически у них своё ядро и ядерным API Windows.

Всё-таки это разные вещи.

да, это делается. вопрос в том что конкретно ты хочешь перенести?

если драйвера сетевух, то ИМХО лучше брать вместе с tcp/ip стеком, который из того же лялеха выдернуть не получится ибо лапша.

если драйвера каких то там мелочевок, где тебе всего то надо по io портам подергать, да обработчик прерываний добавить - такое легко. Надо API в виде библиотеки делать.

монолит или микроядро - особо не важно, просто второе сложнее в реализации, но лучше.

в теории все можно перенести, не обязательно из лялеха, но в лялехе много полезного есть. Проблема в том что это все надо поддерживать, и если брать конкретно лялех, то надо постоянно менять API, потому как в лялихе полоумные погромисты все время меняют API чтобы были коммиты в ядро и побольше. А это уже надо большую команду держать людей.

чем оно будет лучше линукса

ну можно более грамотнее задизайнить его, и это - никаких sjw.

у них своё ядро

Но у них нет какого-то внутреннего ядра с оригинальной архитектурой, в который отображается API совместимости, а просто альтернативная реализация, плюс-минус той же архитектуры. Они не могут куда-то далеко шагнуть в плане новых идей.

если драйвера сетевух, то ИМХО лучше брать вместе с tcp/ip стеком, который из того же лялеха выдернуть не получится ибо лапша

работал я как-то в компании, где одним патчем выпиливался весь netfilter и заменялся на свое поделие.

Возможно инфа шлак, но у меня в голове осталась инфа что в каком то из бсд именно так и делали.

Если реализовать compat-уровень (таймеры, списки, аллокаторы, рабочие очереди, тасклеты и прочее подобное барахло) и нужные глобальные структуры, то почему нет.

ndiswrapper это пример, можешь воспринимать это как некий PoC. такой же wrapper можно создать и для другого класса драйверов и можно создавать в обратную сторону (запускать драйвера linux в windows)

проблема такого подхода в том, что всё ненативное работает всегда хуже (медленнее, ограниченнее по фичам, глючнее) нативного

+новые драйверы могут использовать новый API ядра, а это значит что wrapper должен будет вечно портировать новый API. короче такое себе, эта вечная оглядка на linux будет мешать развитию развитию «навороченному ядры»

работал я как-то в компании, где одним патчем выпиливался весь netfilter и заменялся на свое поделие.

это ж не стек, да и свое поделие может быть заточено под лапшу - так то если.

вообще если говорить про x86 то там много workarounds накоплено под разное железо с разными железными глюками. я б такой проект под x86 не начинал бы вообще.

И это верно. Вопрос: а можно ли написать новое навороченное ядро (или даже микроядро, но необязательно), скажем, на Rust (тоже необязательно), и подрубить к нему драйвера от Linux?

Ну, в общем-то, такие мысли посещали разработчиков GNU HURD и там для определенных устройств драйвера из Linux работают (для сетевых карт, по-моему, точно):

https://www.gnu.org/software/hurd/dde.html

https://www.gnu.org/software/hurd/community/gsoc/project_ideas/driver_glue_co...

Линукс устраивает почти всех. Для тех, кого не устраивает, есть всякие виды BSD, QNX, xxxxRTOS, Windows и даже L4. Встречаются и совсем уж диковинки, но это уж очень узкие применения, а отнюдь не ОС широкого профиля.

Короче говоря, для создания новой ОС широкого профиля сейчас нет ни спроса, ни ресурсов.

для создания новой ОС широкого профиля сейчас нет ни спроса, ни ресурсов

А у меня чот ровно обратное мнение

А зачем было выпиливать, он же отключается?

да - во фряхе есть линукс аби.

сделали