LINUX.ORG.RU
ФорумTalks

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

 , ,


1

2

Когда говорят о создании нового ядра со всякими современными наворотами и плюшками, обычно приводят железный аргумент:

  • Кому оно нужно без драйверов?

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

Deleted

Ответ на: комментарий от srg666

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

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

Deleted ()

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

dem ()
Ответ на: комментарий от Deleted

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

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

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

dem ()
Ответ на: комментарий от dem

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

Чиво?

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

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

Deleted ()

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

cvv ★★★★★ ()

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

TooPar ()
Ответ на: комментарий от Arrest

rump kernel/anykernel

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

TooPar ()

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

insw ()
Последнее исправление: insw (всего исправлений: 1)
Ответ на: комментарий от insw

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

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

Arrest ()
Ответ на: комментарий от Arrest

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

insw ()
Ответ на: комментарий от Arrest

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

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

Deleted ()
Последнее исправление: Deleted (всего исправлений: 1)

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

utf8nowhere ★★ ()
Ответ на: комментарий от Deleted

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

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

Arrest ()

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

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

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

atrus ★★★★★ ()
Ответ на: комментарий от atrus

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

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

Deleted ()

Возможно ли

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

crypt ★★★★★ ()

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

Harald ★★★★★ ()
Ответ на: комментарий от Deleted

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

atrus ★★★★★ ()

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

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

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

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

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

alwayslate ★★ ()
Ответ на: комментарий от Harald

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

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

alwayslate ★★ ()
Ответ на: комментарий от atrus

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

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

gremlin_the_red ★★ ()
Ответ на: комментарий от alwayslate

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

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

DELIRIUM ☆☆☆☆☆ ()
Последнее исправление: DELIRIUM (всего исправлений: 1)

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

pon4ik ★★★★★ ()

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

kirk_johnson ★☆ ()
Ответ на: комментарий от Deleted

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

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

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

srg666 ()
Последнее исправление: srg666 (всего исправлений: 1)
Ответ на: комментарий от DELIRIUM

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

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

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

alwayslate ★★ ()

И это верно. Вопрос: а можно ли написать новое навороченное ядро (или даже микроядро, но необязательно), скажем, на 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...

Zubok ★★★★★ ()

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

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

Deleted ()
Ответ на: комментарий от Deleted

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

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

Deleted ()
Закрыто добавление комментариев для недавно зарегистрированных пользователей (со score < 50)