Профиль: Аноним (вход | регистрация)
The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



"Первый выпуск mklinux для одновременного выполнения нескольких экземпляров ядра Linux"
Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Изначальное сообщение [ Отслеживать ]

"Первый выпуск mklinux для одновременного выполнения нескольких экземпляров ядра Linux"  +/
Сообщение от opennews (??), 26-Авг-26, 11:26 
Представлен первый публичный выпуск проекта Multikernel Linux (mklinux-v7.0-mk2), развивающего вариант ядра Linux, дополненный возможностью выполнения нескольких независимых экземпляров ядра на одном физическом компьютере  без использования гипервизора  и виртуализации. Каждый экземпляр ядра имеет прямой доступ к аппаратным ресурсам и может использоваться для запуска отдельных изолированных системных окружений. Первый выпуск основан на ядре Linux 7.0 и содержит сборочную настройку "CONFIG_MULTIKERNEL", при отключении которой ядро становится полностью аналогично штатному ядру 7.0. Из архитектур CPU пока поддерживается только x86_64...

Подробнее: https://www.opennet.ru/opennews/art.shtml?num=66142

Ответить | Правка | Cообщить модератору

Оглавление

Сообщения [Сортировка по ответам | RSS]

1. Сообщение от Аноним (1), 26-Авг-26, 11:26   –4 +/
Что-то вроде Xen намечается.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #4, #33

2. Сообщение от Аноним (2), 26-Авг-26, 11:26   –3 +/
> высокий уровень изоляции

Насколько, что насчёт Spectre-like уязвимостей?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #23, #27

3. Сообщение от Xasd7 (?), 26-Авг-26, 11:42   +3 +/
чёт не ясно..

будто бы это и хужЕе чем контэйнэрная архитектура... так как содеожит лишнии элементы которое ОДНО ядро молгло бы разруливать...

и одновремено хужЕе чем гипервизор.. так как суть гипервизора как раз в унификации -- а если гипервизора нет -- то как бы херня какая-то чисто архитектурно

Ответить | Правка | Наверх | Cообщить модератору

4. Сообщение от Аноним (4), 26-Авг-26, 11:53   +12 +/
Скорее LPAR
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #77

6. Сообщение от Мемоним (?), 26-Авг-26, 11:59   +2 +/
> Каждый экземпляр выполняется на отдельном выделенном ядре CPU

Получается изолированных ядер Linux не больше чем ядер процессора? Довольно жесткое ограничение по сравнение с гипервизором.

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #28

7. Сообщение от localhostadmin (ok), 26-Авг-26, 12:00   +2 +/
> Каждый экземпляр ядра имеет прямой доступ к аппаратным ресурсам

А как тогда достигается изоляция? Что мне мешает на одном экземпляре прочитать данные с другого, просто через /dev/sda?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #8, #15, #25

8. Сообщение от Мемоним (?), 26-Авг-26, 12:08   –1 +/
Ядра же работают кооперативно и знают где чьё. Они просто не дадут пользователю доступа к ресурсам другого ядра.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #11, #13, #62

9. Сообщение от тожемимокрокодил (?), 26-Авг-26, 12:11   +/
Не очень понятно, это аналог NetBSD-шного RUMP или развитие Siemens-овского Xenomai?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #32

10. Сообщение от Sm0ke85 (ok), 26-Авг-26, 12:14   +1 +/
Мне не очевидна область применения... Какую задачу данная технология решает лучше других... Оно как будто бы во всех задачах имеет существенные минусы... Ну может под какое нить оборудование нужно постарее/новее ядро и я вдруг пременил данного ежа-носорога и далее получил что...? Или использовал вместо виртуалки и что улучшилось, кроме производительности, или хотя бы не ухудшилось...?

Кто-нибудь в курсе: зачем Это...?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #12, #22

11. Сообщение от Sm0ke85 (ok), 26-Авг-26, 12:19   +2 +/
>Ядра же работают кооперативно и знают где чьё. Они просто не дадут пользователю доступа к ресурсам другого ядра.

Так у тебя файловая система вмонтирована в оба ядра, я так понимаю, как другое ядро тебе запретит ее читать...?

Или это просто "куча линуксов" со своей ФС запущенные одновременно? Ну так все равно, если я ломанул один, то я, как бы, могу примонтировать "чужую" ФС в /mnt например и "гулять дальше"...

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #19, #52

12. Сообщение от Аноним (2), 26-Авг-26, 12:20   +2 +/
> зачем

Реклама компании
https://multikernel.io/products/cloud.html
Цитирую - "A per-node annual subscription"

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

13. Сообщение от Аноним (23), 26-Авг-26, 12:23   +1 +/
Тогда непонятно, что даёт такая условная изоляция по сравнению с контейнерами.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8 Ответы: #20

15. Сообщение от похнапоха (?), 26-Авг-26, 12:28   +/
наверное будет нужен некий VIOS, как в IBM Power, либо нужен некая преднастройка кому какое блочное устройство смапить, как в том же IBM Power.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7

16. Сообщение от Аноним (16), 26-Авг-26, 12:34   +3 +/
Пахнет как вагон проблем с гонкой за ресурсами инстансами ядра, без гипервизора то
Ответить | Правка | Наверх | Cообщить модератору

17. Сообщение от Аноним (17), 26-Авг-26, 13:10   +/
Не очень понятно, зачем такое может понадобится. Память на каждое ядро придётся выделить заранее (нет возможности балансировать при нагрузке), устройства - тоже (каждому ядру по своей сетевой карте и жесткому диску. Ну или загрузка по сети).

Т.е. можно запустить на мощном сервере пару десятков "независимых" машинок, но виртуалки дадут почти тот же эффект.

Ответить | Правка | Наверх | Cообщить модератору

18. Сообщение от Аноним (-), 26-Авг-26, 13:11   +1 +/
Эксплуатация одного из ядер даёт почти наверняка доступ ко всем остальным...

В гипервизоре получение права исполнения кода от имени ядра открывает путь к эксплуатации гипервизора. Защита многослойная. А тут... Для контейнеров уж лучше gVisor использовать, если виртуализация совсем не подходит.

Ответить | Правка | Наверх | Cообщить модератору

19. Сообщение от Мемоним (?), 26-Авг-26, 13:28   +/
Да, это компания "дружественных" ядер, где каждое ядро забирает себе часть устройств по согласию. Если ломануть одно, то изоляция ломается. Поэтому безопасность тут слабее, чем с гипервизором.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

20. Сообщение от Мемоним (?), 26-Авг-26, 13:34   +3 +/
> Тогда непонятно, что даёт такая условная изоляция по сравнению с контейнерами.

Ядра с разными настройками (тюнинг под нагрузку), ядра разных версий, живая замена ядра (но нужны отдельные инструменты чтобы перенести приложения с ядра на ядро). И изоляция все-таки более строгая, здесь ты не можешь "выйти из контейнера". Еще юзкейс: повышенная надежность, если одно ядро ушло в кернел паник, другие продолжают работать.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #13 Ответы: #67, #68

21. Сообщение от Жыжа (?), 26-Авг-26, 13:36   +2 +/
> Каждый экземпляр ядра имеет прямой доступ к аппаратным ресурсам
> отдельное ядро в каждом изолированном окружении (...) эксплуатация уязвимости в котором не затрагивает другие окружения

Звучит как взаимосиключающие параграфы, не?

Ответить | Правка | Наверх | Cообщить модератору
Ответы: #24

22. Сообщение от Аноним (22), 26-Авг-26, 14:07   +/
Для лайв апдейтов ядра целиком по А/Б схеме.

в современном мире где приложения изначально готовятся к постоянной потере аптайма неизвестно зачем это нужно

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #10

23. Сообщение от Аноним (23), 26-Авг-26, 14:14   +2 +/
От Spectre даже полноценная виртуалка не защищает.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2 Ответы: #60

24. Сообщение от Аноним (24), 26-Авг-26, 14:29   +/
Ядро можно на и живой системе без перезагрузки обновлять,так что пока сидишь на одном ядре, на другом майнят, а ты и не замечаешь.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #21

25. Сообщение от Ололош (?), 26-Авг-26, 14:49   +/
/dev/sda это виртуальный файл, который генерируется при загрузке ядра, тащем-та, на диске его нет, как и /proc и сокеты там всякие
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #7 Ответы: #46

26. Сообщение от Аноним (26), 26-Авг-26, 15:22   +3 +/
Чем бы не заниматься, лишь бы не разрабатывать ОС на микроядре. Микроядро + контейнеры в принципе самый безопасный вариант.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #89

27. Сообщение от penetrator (?), 26-Авг-26, 15:36   +3 +/
нет там никакой изоляции, даже аппаратные возможности не используются.. очень сомнительно
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #2

28. Сообщение от Аноним (28), 26-Авг-26, 15:45   +/
>Довольно жесткое ограничение производительности будет с гипервизором.

Исправил.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #6 Ответы: #59

30. Сообщение от Аноним (30), 26-Авг-26, 15:59   +1 +/
MkLinux (Microkernel Linux) is a discontinued open-source experimental operating system for PowerPC Macintosh computers. It was launched in 1995 as a collaboration between the Open Software Foundation (OSF) and Apple Computer, as a critical pivot in Apple's technical and social history. MkLinux became Apple's first official free and open-source software community project, and the debut of Linux on the first Power Macintosh.


MkLinux's key feature is its microkernel architecture. Most Linux distributions have a monolithic kernel, but MkLinux is distinguished by its architecture which adapted the Linux kernel to run as a user-space server hosted on top of the Mach microkernel version 3.0. This "single server" architecture makes the system stable and easier to debug, but the overhead of communicating with the microkernel reduces performance.[1]

Ответить | Правка | Наверх | Cообщить модератору

32. Сообщение от Аноним (33), 26-Авг-26, 16:21   +/
Идеи скорее с DrugonFlyBSD.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #9

33. Сообщение от Аноним (33), 26-Авг-26, 16:40   +4 +/
Идея старая и привлекательная. Решает много задач.

Если иметь ядро OS которое паралельно, асинхронно может работать на разных ядрах CPU то:

1. Нет необходимости писать гипервизор. Виртуализация это свойство самого ядра.

2. Нет необходимости писать кластер единого системного образа (SSI). Отдельные ядра на разных компах могут взаимодействовать между собой так же как и на одном многоядерном проце.

3. Говорят это облегчает написание ПО для NUMA систем. Фактически это замена NUMA.

4. Говорят такое ядро будет намного безопаснее. Изоляция приложений выполняемых разными ядрами OS на разных ядрах CPU будет как в виртуализации. Здесь надо внимательно смотреть на реализацию SMP и межядерного взаимодействия. Ядра OS исполняемые на разных ядрах CPU между собой взаимодействуют по специальному внутреядерному протоколу. Падение или взлом одного ядра не приведет к падению или взлому других ядер.

5. Говорят такое ядро может быть более быстрым и асинхронным по типу LWKT.  DrugonFlyBSD имеет такое ядро.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #1 Ответы: #51

34. Сообщение от Аноним (34), 26-Авг-26, 16:42   +3 +/
Отказались от микроядер, но зато породили вот это
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #76

35. Сообщение от tkzv (ok), 26-Авг-26, 17:01   +/
То есть самое нижнее ядро работает гипервизором?
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #80

36. Сообщение от Аноним (36), 26-Авг-26, 17:08   +1 +/
Кто скажет для чего они это сделали?
Ответить | Правка | Наверх | Cообщить модератору

37. Сообщение от Аноним (87), 26-Авг-26, 17:11   +/
Взлетит если запилить под это runk. Отгрызть у контейнеров нишу не получится, у KVM на хостинге таки да.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #49

46. Сообщение от _ (??), 26-Авг-26, 17:56   –1 +/
Ну то есть hypervisor всё таки есть? :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #25 Ответы: #64

47. Сообщение от Chromiumemail (ok), 26-Авг-26, 19:04   –1 +/
Надеюсь, это добьёт Googlebook и Chromebook с их конченными виртуалками
Ответить | Правка | Наверх | Cообщить модератору

49. Сообщение от _ (??), 26-Авг-26, 19:23   +1 +/
Нет не взлетит.
Там в самой идее - дыра. А уж в реализации (если реализуют) ...
И ведь надо ещё на руст переписать, кстати! :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #37

50. Сообщение от Аноним (50), 26-Авг-26, 19:25   –1 +/
Хорошая инициатива. Пусть ещё сделают безшовную миграцию приложений с одного ядра на другое, чтобы апдейты накатывать без ребута.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #66

51. Сообщение от Аноним (51), 26-Авг-26, 19:31   +1 +/
> 4. Говорят такое ядро будет намного безопаснее. Изоляция приложений выполняемых разными ядрами OS на разных ядрах CPU будет как в виртуализации. Здесь надо внимательно смотреть на реализацию SMP и межядерного взаимодействия. Ядра OS исполняемые на разных ядрах CPU между собой взаимодействуют по специальному внутреядерному протоколу. Падение или взлом одного ядра не приведет к падению или взлому других ядер.

осталось такой CPU найти :))

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #33 Ответы: #65, #69, #87

52. Сообщение от Аноним (51), 26-Авг-26, 19:33   +1 +/
куда там до FS, там вероятней L3 кеш общий уже :)
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #11

54. Сообщение от вах (ok), 26-Авг-26, 20:00   +1 +/
Все ждут микроядро и контейнеры!
Ответить | Правка | Наверх | Cообщить модератору

57. Сообщение от Аноним (57), 26-Авг-26, 21:10   –1 +/
Новое - это хорошо забытое старое.
Распределённая на несколько ядер операционная система - это не новинка. Есть повод перечитать старые книжки Таненбаума.
Ответить | Правка | Наверх | Cообщить модератору

58. Сообщение от Аноним (65), 26-Авг-26, 21:52   +1 +/
Анархия какая-то. Как мониторить потребление ресурсов соседом? Пускать второе ядро как часть своего?
Ответить | Правка | Наверх | Cообщить модератору

59. Сообщение от Аноним (65), 26-Авг-26, 22:00   +/
Что исправил? Человек сказал, что Количество ограничено числом ядер. Гипервизор позволяет создать много больше: Некоторые из них полуспящие и не влияют на производительность остальных.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #28

60. Сообщение от Аноним (65), 26-Авг-26, 22:02   +/
И здесь не защищает, так как эту функцию ядра будет брать на себя общее нижнее ядро.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #23

61. Сообщение от Аноним (65), 26-Авг-26, 22:14   +/
Вероятно, сведется всё к собственному формату изоляции вместо обще-специфицированного через VM. Плюс отсутствие полноценного гипервизора будет неуправляемость. Ну или ранний рудкит хостового ядра будет всё наблюдать...
Ответить | Правка | Наверх | Cообщить модератору

62. Сообщение от Аноним (65), 26-Авг-26, 22:17   +/
> работают кооперативно и знают где чьё.

Привет от Windows 95. Там тоже быда "кооперативная многозадачность" вместо вытесняющей NT технологии.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #8

64. Сообщение от Аноним (65), 26-Авг-26, 22:34   +/
Нет. Скорее /dev/sda = /dev/sdax где x - раздел версии ядра.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #46 Ответы: #70

65. Сообщение от Аноним (65), 26-Авг-26, 22:40   –2 +/
Да. Проектировщики ЦПУ были не в курсе новых техзаданий mklinux. )
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

66. Сообщение от Аноним (65), 26-Авг-26, 22:56   +/
А какая версия хостового ядра? Его всё равно надо менять. Так что только back port.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #50 Ответы: #84

67. Сообщение от Аноним (65), 26-Авг-26, 23:00   +/
хостовое ядро тоже имеет версию. "Живая замена ядра" сводится "пускай эти приложения пока поживут на старой версии ядра"
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

68. Сообщение от Аноним (65), 26-Авг-26, 23:04   +1 +/
>здесь ты не можешь "выйти из контейнера".

Вы предлагаете софт решение заменить на аппаратное. Перекинут изоляцию на проектировщиков CPU и контроллеров? Они не будут этому рады и были не в курсе, когда проектировали существующие чипы.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #20

69. Сообщение от maximnik0 (?), 27-Авг-26, 01:09   +/
>осталось такой CPU найти :))

Формально arm и риск-5 с аппаратными контроллерами памяти и атрибутами памяти  таким требованиям отвечает.Правда я читал что сумели прочесть атрибуты на арм на процессоре без контроллера памяти .

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

70. Сообщение от _ (??), 27-Авг-26, 03:28   +/
Но как Холмс?! (С)

Как ты подружишь много ядер на одну железку? А никак!
Поэтому и делают наоборот. Настоящую железку - гипервизору, а вм-ам ... sdax :-)

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #64 Ответы: #71

71. Сообщение от _ (??), 27-Авг-26, 03:29   +/
Короче - "весёлые картинки"(С) это всё. Расходимся поцоны!
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #70

76. Сообщение от жирик (?), 27-Авг-26, 06:32   +/
Unikernel наоборот, да.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #34

77. Сообщение от Диды (ok), 27-Авг-26, 07:18   +1 +/
Или https://github.com/siemens/jailhouse
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #4 Ответы: #90

78. Сообщение от Аноним (78), 27-Авг-26, 08:40   +/
Может реализуют фукнционал смены ядра без перезагрузки системы.
Ответить | Правка | Наверх | Cообщить модератору
Ответы: #81, #82

79. Сообщение от Moebius (ok), 27-Авг-26, 10:54   +/
На mklinux.org что-то про систему для Power Macintosh.
Ответить | Правка | Наверх | Cообщить модератору

80. Сообщение от Ык (?), 27-Авг-26, 11:21   +/
Да, у менятоже вопрос такой. Теперь в линкусе кроме ядер на cpu есть еще верхнее и нижнее ядро?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #35

81. Сообщение от Ык (?), 27-Авг-26, 11:24   +2 +/
Так он уже давно есть жеж?
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78

82. Сообщение от ЭлвисПресли (?), 27-Авг-26, 13:59   +/
Можно менять ядра, как шуллер колоды.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #78

84. Сообщение от Аноним (50), 27-Авг-26, 16:01   +/
Ты точно понял о чём речь? Нет там никакого "хостового" ядра.
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #66 Ответы: #88

85. Сообщение от Аноним (85), 27-Авг-26, 18:23   +/
Ну согласно рекламе на сайте https://multikernel.io/getting-started.html выглядит достаточно интересно.

┌─────────────────┐  ┌─────────────────┐  ┌─────────────────┐
│   Web Server    │  │    Database     │  │   ML Training   │
├─────────────────┤  ├─────────────────┤  ├─────────────────┤
│  Linux Kernel   │  │  Linux Kernel   │  │  Linux Kernel   │
│  (Web-tuned)    │  │  (I/O-optimized)│  │  (GPU-optimized)│
├─────────────────┤  ├─────────────────┤  ├─────────────────┤
│   CPU + NIC     │  │   CPU + NVMe    │  │   CPU + GPU     │
└─────────────────┘  └─────────────────┘  └─────────────────┘


                         Containers     VMs                   Multikernel
Isolation                Shared kernel     Full (hypervisor)     Separate kernels
Performance                Near-native             5-20% overhead           Native
Kernel customization        No                     Yes                   Yes
Dynamic resources        Yes                     Limited           Yes (hotplug)
Zero-downtime updates        App only             With orchestration    Kernel + app
Attack surface                Full kernel             Reduced           Minimal per instance

Ответить | Правка | Наверх | Cообщить модератору

87. Сообщение от Аноним (87), 27-Авг-26, 22:27   +1 +/
Любой. Они вешаются на чипсет на PCI. Если расковырять чипсет, у тебя будет самый настоящий слейв cpu.

Если не играть в слейв cpu - достаточно к паре cpu/chipset прибить реалтек на одну линию PCI и написать драйвер слейва. Как в интелах о 56 ядер атома на PCI сделали.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #51

88. Сообщение от Аноним (88), 28-Авг-26, 01:15   +/
https://multikernel.io/technology.html

Split-Kernel Architecture

The Multikernel system offloads all device drivers and interrupt processing to a dedicated device-kernel. Applications run in isolated app-kernels with dedicated resources and native hardware performance.

Ответить | Правка | Наверх | Cообщить модератору
Родитель: #84

89. Сообщение от Аноним (89), 28-Авг-26, 09:13   +/
отсыпьте, пожалуйста
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #26

90. Сообщение от Аноним (90), 30-Авг-26, 19:43   +/
Нет, jailhouse совсем не так работает. Его фишка в том, что у него нет планировщика, и виртуалке выделяются ядра целиком, но аппаратная виртуализация ему для работы требуется
Ответить | Правка | Наверх | Cообщить модератору
Родитель: #77


Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2026 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру