forum.opennet.ru - "Механизм Kexec HandOver для перезагрузки ядра Linux без потери состояния" (43)

"Механизм Kexec HandOver для перезагрузки ядра Linux без потери состояния"

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

"Механизм Kexec HandOver для перезагрузки ядра Linux без потери состояния"	+/–
Сообщение от opennews (?), 15-Апр-25, 09:59
В списке рассылки ядра Linux представлена шестая версия патчей с реализацией механизма Kexec HandOver (KHO), развиваемого инженерами из компаний Amazon, Microsoft и Google. Патчи уже приняты в ветку mm-everything, в которой осуществляется накопление изменений для будущей ветки ядра 6.16, связанных с управлением памятью. На базе Kexec HandOver компания Google разрабатывает подсистему Live Update Orchestrator (LUO), позволяющую перезагружать ядро без остановки работы устройств... Подробнее: https://www.opennet.dev/opennews/art.shtml?num=63075
Ответить \| Правка \| Cообщить модератору

Оглавление

В промежутках между рестартами эту область памяти можно править как хочешь и зан, Аноним (6), 10:09 , 15-Апр-25, (6) –4

а чё сразу троян не записать в ядро Или не записать троян в dev mem А, точно,, pavel_simple. (?), 10:21 , 15-Апр-25, (8) +13

Более того Если кто-то смог втиснуться куда-то в район kexec - он и так уже в, Аномни (-), 13:58 , 15-Апр-25, (45)
Что бы была возможность понять ответ на риторический вопрос, необходимы осново, n00by (ok), 09:07 , 16-Апр-25, (62)

Но зачем Надежнее заносить трояны и бекдоры прямо в ядро Чтобы потом всякие Bvp4, Аноним (-), 11:28 , 15-Апр-25, (26) +2

Опять этот чудак тут с этим Bvp47, который вообще - совершенно отдельная приблуд, Аноним (43), 13:53 , 15-Апр-25, (43)

Чувак, если у тебя кто-то правит память прямо когда старый кернел отдает управле, Аноним (-), 13:56 , 15-Апр-25, (44) +1

Некоторые вещи из всё что пожелает делать не так просто Например, реализовать, n00by (ok), 09:12 , 16-Апр-25, (63)

Я не знаю, почему, на опенсурцеры почему то не дружат с сохранением состояний М, Аноним (7), 10:16 , 15-Апр-25, (7) –12

ну, и где хоть в одной оси написаной на модном ооп-язычке есть что-то типа kexec, pavel_simple. (?), 10:23 , 15-Апр-25, (10) +7

так они на немодных Надо попробовать на брейнфаке , нах. (?), 11:53 , 15-Апр-25, (29)

Скрыто модератором, Аноним (12), 10:24 , 15-Апр-25, (12)

Скрыто модератором, pavel_simple. (?), 10:57 , 15-Апр-25, (20)

Скрыто модератором, Аноним (12), 11:21 , 15-Апр-25, (25) +1

Скрыто модератором, pavel_simple. (?), 12:50 , 15-Апр-25, (31)

Скрыто модератором, Аноним (12), 13:13 , 15-Апр-25, (36)

Для этого не нужно ооп Думаешь структуры нельзя сохранить хоть куда Звучит по , Аноним (16), 10:41 , 15-Апр-25, (16) +2
А кто тебе сказал что проблема в сохранении состояния Его если нужно - сохранит, windows10 (ok), 10:47 , 15-Апр-25, (17) +2

Все проще- она иноагент не шпрехающий по русски , ss (??), 08:38 , 16-Апр-25, (58)

Как сохранить указатель Вот то-то же и оно Да и зачем ООП, когда просто структ, Аноним (18), 10:52 , 15-Апр-25, (18) +2

да да, ни разу не видел класс без указателей в реальном проекте, а потом появляю, nikitron (ok), 11:20 , 15-Апр-25, (24)
В смысле Берешь и сохраняешь Ессно не трогая регион на который он указывает Е, Аноним (-), 14:10 , 15-Апр-25, (47)

А проприетарщики типа дружат Это кто Винда чтоли, которая я луше знаю - вам п, Аноним (-), 13:32 , 15-Апр-25, (40)
Каждый раз думаю, все, хорош читать коменты на опеннете, но блин, ради таких ге, OpenEcho (?), 15:20 , 15-Апр-25, (49) +1
Троллите, или вам просто лень посмотреть на реализацию сохранения и загрузки объ, Аноним (54), 17:29 , 15-Апр-25, (54) +1

А можно написать команду как меняется переход то , Аноним (11), 10:24 , 15-Апр-25, (11)
Такое уже было и даже в нескольких видах И умирало потому что особо никому не н, Аноним (19), 10:54 , 15-Апр-25, (19)

При чём тут нельзя Просто зачем делать перебой, если его можно не делать , Аноним (23), 11:16 , 15-Апр-25, (23)

Решается покупкой второго компьютера и использованием системы с передачей управл, Аноним (54), 17:31 , 15-Апр-25, (55) +1

Как по мне это все костыли для монолитного монстра Нужно сохранять состояния си, Аноним (27), 11:34 , 15-Апр-25, (27)

QNX научился обновлять ядро без остановки приложений , pavel_simple. (?), 13:02 , 15-Апр-25, (35) +1
И конечно вы нам насыпете сейчас пруфлинк что оно так вообще умеет, прозрачно дл, Аноним (-), 13:41 , 15-Апр-25, (41) –1

Он не будет это делать, пока нет _доказательства_, что так умеет linux Прохожде, n00by (ok), 09:23 , 16-Апр-25, (64)

Когда корпы начинают лезть во что то хорошее, то это хорошее становится злом Пре, Андрей (??), 13:31 , 15-Апр-25, (39)

Корпы хотят инфру с минимальными дайнтаймами Это является мотиватором к вджобу , Аноним (-), 13:42 , 15-Апр-25, (42) +1
Если бы корпы не влезали в это хорошее, то оно так бы осталось студенческим бало, OpenEcho (?), 15:27 , 15-Апр-25, (50)

Кстати, до сих пор весь мой прикладной софт написан студентами и или дилетантами, Аноним (12), 16:16 , 15-Апр-25, (51)

А почему нельзя было просто сделать то же самое, корректно написав выгрузку драй, slavanap (?), 18:19 , 15-Апр-25, (56)

потому что цель- в обновлении ядра а не в этом драйвере , ss (??), 08:42 , 16-Апр-25, (60)

Как изнутри системы виртуальной машины определить, что ты потерял время и была , Аноним (57), 23:01 , 15-Апр-25, (57) +2

навернео по расхождению часов с внешним истоником Кстати это можно делать и не , ss (??), 08:42 , 16-Апр-25, (59) +1

Для нас цикл цефеид по идее останется стабильным - он ведь часть матрицы если с, Аноним (65), 10:18 , 16-Апр-25, (65)

И лайвпатч сразу стал не нужен , Аноним (61), 08:45 , 16-Апр-25, (61)

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

6. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." –4 +/–

Сообщение от Аноним (6), 15-Апр-25, 10:09

В промежутках между рестартами эту область памяти можно править как хочешь и занести троян.

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

8. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +13 +/–

Сообщение от pavel_simple. (?), 15-Апр-25, 10:21

> В промежутках между рестартами эту область памяти можно править как хочешь и
> занести троян.
а чё сразу троян не записать в ядро? Или не записать троян в /dev/mem? А, точно, права же нужны

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

45. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +/–

Сообщение от Аномни (-), 15-Апр-25, 13:58

> а чё сразу троян не записать в ядро? Или не записать троян
> в /dev/mem? А, точно, права же нужны
Более того. Если кто-то смог втиснуться куда-то в район kexec() - он и так уже все полномочия давно имел. А /dev/mem можно и зарубить, в режиме lockdown вы фиг пропатчите им память ядра. Даже от рута.

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

62. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +/–

Сообщение от n00by (ok), 16-Апр-25, 09:07

>> В промежутках между рестартами эту область памяти можно править как хочешь и
>> занести троян.
> а чё сразу троян не записать в ядро? Или не записать троян
> в /dev/mem? А, точно, права же нужны
Что бы была возможность понять ответ на "риторический" вопрос, необходимы основополагающие знания, что есть алгоритм.
Алгоритм такой:
1. Получаем права.
2. Пишем троян.
И не надо засыпать риторическими вопросами "как ты получишь права?" и "где мне скачать зеродей?"

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

26. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +2 +/–

Сообщение от Аноним (-), 15-Апр-25, 11:28

> можно править как хочешь и занести троян.
Но зачем?
Надежнее заносить трояны и бекдоры прямо в ядро.
Чтобы потом всякие Bvp47 жили по 10 лет.

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

43. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +/–

Сообщение от Аноним (43), 15-Апр-25, 13:53

> Надежнее заносить трояны и бекдоры прямо в ядро.
> Чтобы потом всякие Bvp47 жили по 10 лет.
Опять этот чудак тут с этим Bvp47, который вообще - совершенно отдельная приблуда и Linux "виноват" только тем что эта штука и его решила поддерживать. Но оно и не только на линухе работает, и это же можно пре.
Видимо этот горе-анон надеялся что никто не дойдет даже до вики, почитать что такое Bvp47. Но этот хитрый план потерпел неудачу.

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

44. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +1 +/–

Сообщение от Аноним (-), 15-Апр-25, 13:56

> В промежутках между рестартами эту область памяти можно править как хочешь и
> занести троян.
Чувак, если у тебя кто-то правит память прямо когда старый кернел отдает управление новому - у тебя в системах и так уже был жирнейший троян, со всеми полномочиями. Более того - этот троян уже имел абсолютный контроль над системой и всяко мог делать все что пожелает.

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

63. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +/–

Сообщение от n00by (ok), 16-Апр-25, 09:12

Некоторые вещи из всё "что пожелает" делать не так просто. Например, реализовать stop_machine() без вызова stop_machine().

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

7. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." –12 +/–

Сообщение от Аноним (7), 15-Апр-25, 10:16

Я не знаю, почему, на опенсурцеры почему то не дружат с сохранением состояний. Может это потому, что они юзают си, где нет ооп в явном виде. При наличии ооп задача сохранения состояния объекта обычно становится тривиальной. Ты запихиваешь все свойства объекта в класс. Когда надо, ты без всякой сериализации просто сохраняешь память объекта куда тебе надо. Хоть в файл, хоть в другую область памяти, хоть куда.

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

10. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +7 +/–

Сообщение от pavel_simple. (?), 15-Апр-25, 10:23

> Я не знаю, почему, на опенсурцеры почему то не дружат с сохранением
> состояний. Может это потому, что они юзают си, где нет ооп
> в явном виде. При наличии ооп задача сохранения состояния объекта обычно
> становится тривиальной. Ты запихиваешь все свойства объекта в класс. Когда надо,
> ты без всякой сериализации просто сохраняешь память объекта куда тебе надо.
> Хоть в файл, хоть в другую область памяти, хоть куда.
ну, и где хоть в одной оси написаной на модном ооп-язычке есть что-то типа kexec хотяб в старом виде? Может не в опенсорсной макоси или вынде?

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

29. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +/–

Сообщение от нах. (?), 15-Апр-25, 11:53

> Может не в опенсорсной макоси или вынде?
так они на немодных.
Надо попробовать на брейнфаке!

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

12. Скрыто модератором +/–

Сообщение от Аноним (12), 15-Апр-25, 10:24

При обновлении соснёшь. При переносе на другое железо соснёшь.

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

20. Скрыто модератором +/–

Сообщение от pavel_simple. (?), 15-Апр-25, 10:57

> При обновлении соснёшь. При переносе на другое железо соснёшь.
такое ощющение что ты пишешь не приходя в сознание, какой kexec при смене железа? Ты вообще в букавы умеешь?

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

25. Скрыто модератором +1 +/–

Сообщение от Аноним (12), 15-Апр-25, 11:21

Он утверждает, что сериализация -- оверинжиниринг. Это не так. При чём тут kexec, у тебя всё хорошо?

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

31. Скрыто модератором +/–

Сообщение от pavel_simple. (?), 15-Апр-25, 12:50

> Он утверждает, что сериализация -- оверинжиниринг. Это не так. При чём тут
> kexec, у тебя всё хорошо?
ты знаешь что такое контекст обчуждения? Топик от kexec. Сериализовывать оперативную память -- это прям эпик вин

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

36. Скрыто модератором +/–

Сообщение от Аноним (12), 15-Апр-25, 13:13

Совершенно очевидно, он говорил это вне контекста. А чё ты ещё с памятью сделаешь? Ты же не возьмёшь и сохранишь как оно есть в памяти, нужно разбираться, что сохранять и откуда. А потом ты заменишь какой-нибудь код или обновишь версии компонентов тулчейна и без процесса десериализации всё развалится.

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

16. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +2 +/–

Сообщение от Аноним (16), 15-Апр-25, 10:41

> Когда надо, ты без всякой сериализации просто сохраняешь память объекта куда тебе надо.
Для этого не нужно ооп. Думаешь структуры нельзя сохранить хоть куда? Звучит по меньшей мере странно.

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

17. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +2 +/–

Сообщение от windows10 (ok), 15-Апр-25, 10:47

> Я не знаю, почему, на опенсурцеры почему то не дружат с сохранением состояний. Может это потому, что они юзают си, где нет ооп в явном виде. При наличии ооп задача сохранения состояния объекта обычно становится тривиальной. Ты запихиваешь все свойства объекта в класс. Когда надо, ты без всякой сериализации просто сохраняешь память объекта куда тебе надо. Хоть в файл, хоть в другую область памяти, хоть куда.
А кто тебе сказал что проблема в сохранении состояния? Его если нужно - сохранить не трудно, даже на уровне прикладного ПО.
Проблема в пересчитывании состояний. Вот возьми любой свой язык (ну желательно конечно из более менее популярных), где есть понятие инклудов.
Напиши на нем какую-нибудь либу, ну там lib.php, lib.py, lib.c, lib.pas - неважно. В этой либе напиши какую-нибудь функцию. Например function hello_world, которая просто выводит print("Hello World\n") - на любом из твоих ЯП, неважно.
И напиши программу, которая инклудит эту либу, и скажем так, вызывает в периодическом цикле функцию hello_world() из твоей либы. Запусти ее. У тебя выводится Hello World.
Потом в своей либе поменяй print("Hello World\n") на print("Привет Мир\n"). Ну то есть мы типа обновили либу.
И вот тут начинаются проблемы. Ведь твоя программа не стала выводить Привет Мир, она по прежнему выводит Hello World. А ведь здесь по сути даже состояний нет - здесь просто вывод одной строчки.

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

58. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +/–

Сообщение от ss (??), 16-Апр-25, 08:38

Все проще- она иноагент не шпрехающий по русски...

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

18. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +2 +/–

Сообщение от Аноним (18), 15-Апр-25, 10:52

> просто сохраняешь память объекта куда тебе надо
Как сохранить указатель? Вот то-то же и оно. Да и зачем ООП, когда просто структа достаточно? По твоей же логике, просто берем и делаем memcpy всего структа куда надо.

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

24. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +/–

Сообщение от nikitron (ok), 15-Апр-25, 11:20

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

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

47. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +/–

Сообщение от Аноним (-), 15-Апр-25, 14:10

>> просто сохраняешь память объекта куда тебе надо
> Как сохранить указатель? Вот то-то же и оно.
В смысле? Берешь и сохраняешь. Ессно не трогая регион на который он указывает. Если регион никто не телепал (это кто-то должен делать явно) - если указатель показывал на адрес 42 ДО операции, и после восстановления показывает на адрес 42, и по адресу 42 никто ничего не менял - окей, и в чем проблема? RAM так то сам по себе не теряет данные, если что.
Прикинь, допустим нажатие кнопки RESET само по себе вообще RAM не очищает?! Это кто-то должен явно пройтись по всем адресам и протереть это. Иначе там останется то что было на момент ресета, ВНЕЗАПНО.
> Да и зачем ООП, когда просто структа достаточно? По твоей же логике, просто берем и
> делаем memcpy всего структа куда надо.
А что если этот {объект, структ} в новой версии немного изменился например? :)

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

40. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +/–

Сообщение от Аноним (-), 15-Апр-25, 13:32

> Я не знаю, почему, на опенсурцеры почему то не дружат с сохранением состояний.
А проприетарщики типа дружат? Это кто? Винда чтоли, которая "я луше знаю - вам пора в ребут, вот вам!" - и пользователь такой "ах ты блин, я файлы не засэйвил, куда?!"
> Может это потому, что они юзают си, где нет ооп в явном виде.
Покажи свое ядро на чем угодно которое вообще сможет вон то, как это, сишное.
> При наличии ооп задача сохранения состояния объекта обычно становится тривиальной.
Теперь повтори это же для более 9000 оных, а также девайсов живущих своей жизнью, особенно развеселых вещей типа DMA, работающих вообще side by side с процом независимо от него. Чтоб какой DMA не уронил бы все в процессе. Апликущники вообще не в курсе как все это работает.
> Ты запихиваешь все свойства объекта в класс. Когда надо, ты без всякой
> сериализации просто сохраняешь память объекта куда тебе надо.
И конечно в новом ядре - оно вот прямо всенепременно обязано на 100% совпадать, ды? Что делать если в новом ядре это немного изменилось и старая версия напрямую не котируется - мы подумаем потом, видимо.
Более того - по дефолту ядро видите ли дейтвовало так что его запустили из бутлоадера, оно считало себя первым кто раскочегаривает систиему. Так что вот вся инициализация памяти, девайсов и чего там. С ноля. В этот момент ваши виртуалки, конечно, перестанут существовать. Вообще совсем. О том что ядро надо явно информировать что это НЕ запуск из бутлоадера и надо именно не рушить состояние и сделать трансфер оного - мы тоже подумаем потом видимо. А задним то умом все крепкие. Когда фичу за вас уже запилили - тогда просто.
> Хоть в файл, хоть в другую область памяти, хоть куда.
Как говорится, было просто на бумаге, да забыли про овраги.

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

49. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +1 +/–

Сообщение от OpenEcho (?), 15-Апр-25, 15:20

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

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

54. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +1 +/–

Сообщение от Аноним (54), 15-Апр-25, 17:29

Троллите, или вам просто лень посмотреть на реализацию сохранения и загрузки объекта? Нихрена там не тривиально, особенно с методами. По сути нужно чуть ли не ELF-файл дампить, чтобы потом обратно ваш "объект" загрузить.

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

11. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +/–

Сообщение от Аноним (11), 15-Апр-25, 10:24

А можно написать команду как меняется переход то?

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

19. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +/–

Сообщение от Аноним (19), 15-Апр-25, 10:54

Такое уже было и даже в нескольких видах. И умирало потому что особо никому не нужно было. На самом деле "когда остановка недопустима и необходимо обеспечить непрерывный цикл работы отдельных устройств." _очень_ узкая прослойка, сходу даже и не скажешь, где нельзя остановиться, но, где прям кровь из носу, нужно зачем-то обновиться.

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

23. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +/–

Сообщение от Аноним (23), 15-Апр-25, 11:16

При чём тут "нельзя"? Просто зачем делать перебой, если его можно не делать?

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

55. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +1 +/–

Сообщение от Аноним (54), 15-Апр-25, 17:31

Решается покупкой второго компьютера и использованием системы с передачей управления в него от выключаемого. Другой вопрос, почему перезагрузка вдруг стала "дорогой", медленной операцией.

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

27. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +/–

Сообщение от Аноним (27), 15-Апр-25, 11:34

Как по мне это все костыли для монолитного монстра. Нужно сохранять состояния системы, для того что бы обновиться в рилтайм? Используйте QNX или другие системы с модульным микроядром. А если уж приспичело обновлять монолитное ядро то реализацию нужно возлагать на разработчиков модулей и софта, а не патчи придумывать ...
Взгляд с другой стороны

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

35. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +1 +/–

Сообщение от pavel_simple. (?), 15-Апр-25, 13:02

> Как по мне это все костыли для монолитного монстра. Нужно сохранять состояния
> системы, для того что бы обновиться в рилтайм? Используйте QNX или
> другие системы с модульным микроядром. А если уж приспичело обновлять монолитное
> ядро то реализацию нужно возлагать на разработчиков модулей и софта, а
> не патчи придумывать ...
> Взгляд с другой стороны
QNX научился обновлять ядро без остановки приложений?

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

41. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." –1 +/–

Сообщение от Аноним (-), 15-Апр-25, 13:41

> для того что бы обновиться в рилтайм? Используйте QNX или другие системы с
> модульным микроядром.
И конечно вы нам насыпете сейчас пруфлинк что оно так вообще умеет, прозрачно для юзермода?
И кстати вот что-что а реалтайм при таком - несколько идет нахрен. Ибо пока ядро реинициализируется, весь юзермод, таки - подождет. Однако реальное время штука относительная. Вот смотрите. Вы видите этот браузер. И меня в нем. У меня это даже виртуалка. Если оно на пару секунд притормозит - и растормозится - это будет не особо заметно. А ядро - вот - обновилось. Это как оно в идеале выглядит. Т.е. для софта это небольшая пауза, типа как при лив миграции VM и процессов. Только теперь это не миграция - а замена кернела прям на лету.
> А если уж приспичело обновлять монолитное ядро то реализацию нужно
> возлагать на разработчиков модулей и софта, а не патчи придумывать ...
Как говорится, кто лучше всех знает как надо - тот это и показывает. Делом. А так то давать мастерклассы гуглу, амазону и майкрософту как софт девелопать для нонсофт инфры? Аноны опеннета бьют просто рекорды наглости.
И за, где там всякие сингулярити от майкрософт? А, что, они пришли к идее что проще из линуха сделать сообща с другими то что им на самом деле хотелось в инфре? :))

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

64. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +/–

Сообщение от n00by (ok), 16-Апр-25, 09:23

>> для того что бы обновиться в рилтайм? Используйте QNX или другие системы с
>> модульным микроядром.
> И конечно вы нам насыпете сейчас пруфлинк что оно так вообще умеет,
> прозрачно для юзермода?
Он не будет это делать, пока нет _доказательства_, что так умеет linux. Прохождение тестов (подтверждение в частных случаях) не является доказательством корректности в общем случае. Прюфлинк называется "чистая функция".
P.S. да, я знаю, кому отвечаю, потому советую не трудиться с очередной порцией "риторики".

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

39. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +/–

Сообщение от Андрей (??), 15-Апр-25, 13:31

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

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

42. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +1 +/–

Сообщение от Аноним (-), 15-Апр-25, 13:42

> Когда корпы начинают лезть во что то хорошее, то это хорошее становится злом.Предлоги не важны.
Корпы хотят инфру с минимальными дайнтаймами. Это является мотиватором к вджобу над вон тем. А вы нас за столько лет ничем на эту тему не осчастливили. Поэтому вы ни хорошее, ни плохое. Вы - никакое. Void вообще не подлежит сравнению.

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

50. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +/–

Сообщение от OpenEcho (?), 15-Апр-25, 15:27

> Когда корпы начинают лезть во что то хорошее
Если бы корпы не влезали в это хорошее, то оно так бы осталось студенческим баловством одного финского студента, вовремя подсуетившегося, пока других студентов нагнула банда "законников"

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

51. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +/–

Сообщение от Аноним (12), 15-Апр-25, 16:16

Кстати, до сих пор весь мой прикладной софт написан студентами и/или дилетантами. Ядро большого значения тут не имеет. Ну и толку от корп? Корпы решают только свои задачи.

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

56. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +/–

Сообщение от slavanap (?), 15-Апр-25, 18:19

А почему нельзя было просто сделать то же самое, корректно написав выгрузку драйвера гипервизора с сохранением состояния? Нафига всё ядро обновлять?

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

60. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +/–

Сообщение от ss (??), 16-Апр-25, 08:42

потому что цель- в обновлении ядра а не в этом драйвере...

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

57. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +2 +/–

Сообщение от Аноним (57), 15-Апр-25, 23:01

Как изнутри системы/виртуальной машины определить, что ты потерял время и была "заморозка" или пауза при работе?

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

59. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +1 +/–

Сообщение от ss (??), 16-Апр-25, 08:42

навернео по расхождению часов с внешним истоником. Кстати это можно делать и не в ВМ. Если обнаружить что цикл цефеид вдруг стал нестабильным - то наверное мы всетаки живем в матрице

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

65. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +/–

Сообщение от Аноним (65), 16-Апр-25, 10:18

Для нас цикл цефеид по идее останется стабильным - он ведь часть матрицы (если считать, что мы в матрице).
Нет оснований считать, что если уж мы в матрице, то цефеиды почему-то вне неё.

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

61. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..." +/–

Сообщение от Аноним (61), 16-Апр-25, 08:45

И лайвпатч сразу стал не нужен.

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

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

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

Партнёры:

Хостинг:

Закладки на сайте
Проследить за страницей

Created 1996-2025 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру

6. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..."	–4 +/–
Сообщение от Аноним (6), 15-Апр-25, 10:09
В промежутках между рестартами эту область памяти можно править как хочешь и занести троян.
Ответить \| Правка \| Наверх \| Cообщить модератору


	8. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..."	+13 +/–
	Сообщение от pavel_simple. (?), 15-Апр-25, 10:21
	> В промежутках между рестартами эту область памяти можно править как хочешь и > занести троян. а чё сразу троян не записать в ядро? Или не записать троян в /dev/mem? А, точно, права же нужны
	Ответить \| Правка \| Наверх \| Cообщить модератору


	45. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..."	+/–
	Сообщение от Аномни (-), 15-Апр-25, 13:58
	> а чё сразу троян не записать в ядро? Или не записать троян > в /dev/mem? А, точно, права же нужны Более того. Если кто-то смог втиснуться куда-то в район kexec() - он и так уже все полномочия давно имел. А /dev/mem можно и зарубить, в режиме lockdown вы фиг пропатчите им память ядра. Даже от рута.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	62. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..."	+/–
	Сообщение от n00by (ok), 16-Апр-25, 09:07
	>> В промежутках между рестартами эту область памяти можно править как хочешь и >> занести троян. > а чё сразу троян не записать в ядро? Или не записать троян > в /dev/mem? А, точно, права же нужны Что бы была возможность понять ответ на "риторический" вопрос, необходимы основополагающие знания, что есть алгоритм. Алгоритм такой: 1. Получаем права. 2. Пишем троян. И не надо засыпать риторическими вопросами "как ты получишь права?" и "где мне скачать зеродей?"
	Ответить \| Правка \| К родителю #8 \| Наверх \| Cообщить модератору


	26. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..."	+2 +/–
	Сообщение от Аноним (-), 15-Апр-25, 11:28
	> можно править как хочешь и занести троян. Но зачем? Надежнее заносить трояны и бекдоры прямо в ядро. Чтобы потом всякие Bvp47 жили по 10 лет.
	Ответить \| Правка \| К родителю #6 \| Наверх \| Cообщить модератору


	43. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..."	+/–
	Сообщение от Аноним (43), 15-Апр-25, 13:53
	> Надежнее заносить трояны и бекдоры прямо в ядро. > Чтобы потом всякие Bvp47 жили по 10 лет. Опять этот чудак тут с этим Bvp47, который вообще - совершенно отдельная приблуда и Linux "виноват" только тем что эта штука и его решила поддерживать. Но оно и не только на линухе работает, и это же можно пре. Видимо этот горе-анон надеялся что никто не дойдет даже до вики, почитать что такое Bvp47. Но этот хитрый план потерпел неудачу.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	44. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..."	+1 +/–
	Сообщение от Аноним (-), 15-Апр-25, 13:56
	> В промежутках между рестартами эту область памяти можно править как хочешь и > занести троян. Чувак, если у тебя кто-то правит память прямо когда старый кернел отдает управление новому - у тебя в системах и так уже был жирнейший троян, со всеми полномочиями. Более того - этот троян уже имел абсолютный контроль над системой и всяко мог делать все что пожелает.
	Ответить \| Правка \| К родителю #6 \| Наверх \| Cообщить модератору


	63. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..."	+/–
	Сообщение от n00by (ok), 16-Апр-25, 09:12
	Некоторые вещи из всё "что пожелает" делать не так просто. Например, реализовать stop_machine() без вызова stop_machine().
	Ответить \| Правка \| Наверх \| Cообщить модератору

7. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..."	–12 +/–
Сообщение от Аноним (7), 15-Апр-25, 10:16
Я не знаю, почему, на опенсурцеры почему то не дружат с сохранением состояний. Может это потому, что они юзают си, где нет ооп в явном виде. При наличии ооп задача сохранения состояния объекта обычно становится тривиальной. Ты запихиваешь все свойства объекта в класс. Когда надо, ты без всякой сериализации просто сохраняешь память объекта куда тебе надо. Хоть в файл, хоть в другую область памяти, хоть куда.
Ответить \| Правка \| Наверх \| Cообщить модератору


	10. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..."	+7 +/–
	Сообщение от pavel_simple. (?), 15-Апр-25, 10:23
	> Я не знаю, почему, на опенсурцеры почему то не дружат с сохранением > состояний. Может это потому, что они юзают си, где нет ооп > в явном виде. При наличии ооп задача сохранения состояния объекта обычно > становится тривиальной. Ты запихиваешь все свойства объекта в класс. Когда надо, > ты без всякой сериализации просто сохраняешь память объекта куда тебе надо. > Хоть в файл, хоть в другую область памяти, хоть куда. ну, и где хоть в одной оси написаной на модном ооп-язычке есть что-то типа kexec хотяб в старом виде? Может не в опенсорсной макоси или вынде?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	29. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..."	+/–
	Сообщение от нах. (?), 15-Апр-25, 11:53
	> Может не в опенсорсной макоси или вынде? так они на немодных. Надо попробовать на брейнфаке!
	Ответить \| Правка \| Наверх \| Cообщить модератору


	12. Скрыто модератором	+/–
	Сообщение от Аноним (12), 15-Апр-25, 10:24
	При обновлении соснёшь. При переносе на другое железо соснёшь.
	Ответить \| Правка \| К родителю #7 \| Наверх \| Cообщить модератору


	20. Скрыто модератором	+/–
	Сообщение от pavel_simple. (?), 15-Апр-25, 10:57
	> При обновлении соснёшь. При переносе на другое железо соснёшь. такое ощющение что ты пишешь не приходя в сознание, какой kexec при смене железа? Ты вообще в букавы умеешь?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	25. Скрыто модератором	+1 +/–
	Сообщение от Аноним (12), 15-Апр-25, 11:21
	Он утверждает, что сериализация -- оверинжиниринг. Это не так. При чём тут kexec, у тебя всё хорошо?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	31. Скрыто модератором	+/–
	Сообщение от pavel_simple. (?), 15-Апр-25, 12:50
	> Он утверждает, что сериализация -- оверинжиниринг. Это не так. При чём тут > kexec, у тебя всё хорошо? ты знаешь что такое контекст обчуждения? Топик от kexec. Сериализовывать оперативную память -- это прям эпик вин
	Ответить \| Правка \| Наверх \| Cообщить модератору


	36. Скрыто модератором	+/–
	Сообщение от Аноним (12), 15-Апр-25, 13:13
	Совершенно очевидно, он говорил это вне контекста. А чё ты ещё с памятью сделаешь? Ты же не возьмёшь и сохранишь как оно есть в памяти, нужно разбираться, что сохранять и откуда. А потом ты заменишь какой-нибудь код или обновишь версии компонентов тулчейна и без процесса десериализации всё развалится.
	Ответить \| Правка \| Наверх \| Cообщить модератору


	16. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..."	+2 +/–
	Сообщение от Аноним (16), 15-Апр-25, 10:41
	> Когда надо, ты без всякой сериализации просто сохраняешь память объекта куда тебе надо. Для этого не нужно ооп. Думаешь структуры нельзя сохранить хоть куда? Звучит по меньшей мере странно.
	Ответить \| Правка \| К родителю #7 \| Наверх \| Cообщить модератору


	17. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..."	+2 +/–
	Сообщение от windows10 (ok), 15-Апр-25, 10:47
	> Я не знаю, почему, на опенсурцеры почему то не дружат с сохранением состояний. Может это потому, что они юзают си, где нет ооп в явном виде. При наличии ооп задача сохранения состояния объекта обычно становится тривиальной. Ты запихиваешь все свойства объекта в класс. Когда надо, ты без всякой сериализации просто сохраняешь память объекта куда тебе надо. Хоть в файл, хоть в другую область памяти, хоть куда. А кто тебе сказал что проблема в сохранении состояния? Его если нужно - сохранить не трудно, даже на уровне прикладного ПО. Проблема в пересчитывании состояний. Вот возьми любой свой язык (ну желательно конечно из более менее популярных), где есть понятие инклудов. Напиши на нем какую-нибудь либу, ну там lib.php, lib.py, lib.c, lib.pas - неважно. В этой либе напиши какую-нибудь функцию. Например function hello_world, которая просто выводит print("Hello World\n") - на любом из твоих ЯП, неважно. И напиши программу, которая инклудит эту либу, и скажем так, вызывает в периодическом цикле функцию hello_world() из твоей либы. Запусти ее. У тебя выводится Hello World. Потом в своей либе поменяй print("Hello World\n") на print("Привет Мир\n"). Ну то есть мы типа обновили либу. И вот тут начинаются проблемы. Ведь твоя программа не стала выводить Привет Мир, она по прежнему выводит Hello World. А ведь здесь по сути даже состояний нет - здесь просто вывод одной строчки.
	Ответить \| Правка \| К родителю #7 \| Наверх \| Cообщить модератору


	58. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..."	+/–
	Сообщение от ss (??), 16-Апр-25, 08:38
	Все проще- она иноагент не шпрехающий по русски...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	18. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..."	+2 +/–
	Сообщение от Аноним (18), 15-Апр-25, 10:52
	> просто сохраняешь память объекта куда тебе надо Как сохранить указатель? Вот то-то же и оно. Да и зачем ООП, когда просто структа достаточно? По твоей же логике, просто берем и делаем memcpy всего структа куда надо.
	Ответить \| Правка \| К родителю #7 \| Наверх \| Cообщить модератору


	24. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..."	+/–
	Сообщение от nikitron (ok), 15-Апр-25, 11:20
	да да, ни разу не видел класс без указателей в реальном проекте, а потом появляются разные пергурзки операторов, чтобы его в/из стрима доставать...
	Ответить \| Правка \| Наверх \| Cообщить модератору


	47. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..."	+/–
	Сообщение от Аноним (-), 15-Апр-25, 14:10
	>> просто сохраняешь память объекта куда тебе надо > Как сохранить указатель? Вот то-то же и оно. В смысле? Берешь и сохраняешь. Ессно не трогая регион на который он указывает. Если регион никто не телепал (это кто-то должен делать явно) - если указатель показывал на адрес 42 ДО операции, и после восстановления показывает на адрес 42, и по адресу 42 никто ничего не менял - окей, и в чем проблема? RAM так то сам по себе не теряет данные, если что. Прикинь, допустим нажатие кнопки RESET само по себе вообще RAM не очищает?! Это кто-то должен явно пройтись по всем адресам и протереть это. Иначе там останется то что было на момент ресета, ВНЕЗАПНО. > Да и зачем ООП, когда просто структа достаточно? По твоей же логике, просто берем и > делаем memcpy всего структа куда надо. А что если этот {объект, структ} в новой версии немного изменился например? :)
	Ответить \| Правка \| К родителю #18 \| Наверх \| Cообщить модератору


	40. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..."	+/–
	Сообщение от Аноним (-), 15-Апр-25, 13:32
	> Я не знаю, почему, на опенсурцеры почему то не дружат с сохранением состояний. А проприетарщики типа дружат? Это кто? Винда чтоли, которая "я луше знаю - вам пора в ребут, вот вам!" - и пользователь такой "ах ты блин, я файлы не засэйвил, куда?!" > Может это потому, что они юзают си, где нет ооп в явном виде. Покажи свое ядро на чем угодно которое вообще сможет вон то, как это, сишное. > При наличии ооп задача сохранения состояния объекта обычно становится тривиальной. Теперь повтори это же для более 9000 оных, а также девайсов живущих своей жизнью, особенно развеселых вещей типа DMA, работающих вообще side by side с процом независимо от него. Чтоб какой DMA не уронил бы все в процессе. Апликущники вообще не в курсе как все это работает. > Ты запихиваешь все свойства объекта в класс. Когда надо, ты без всякой > сериализации просто сохраняешь память объекта куда тебе надо. И конечно в новом ядре - оно вот прямо всенепременно обязано на 100% совпадать, ды? Что делать если в новом ядре это немного изменилось и старая версия напрямую не котируется - мы подумаем потом, видимо. Более того - по дефолту ядро видите ли дейтвовало так что его запустили из бутлоадера, оно считало себя первым кто раскочегаривает систиему. Так что вот вся инициализация памяти, девайсов и чего там. С ноля. В этот момент ваши виртуалки, конечно, перестанут существовать. Вообще совсем. О том что ядро надо явно информировать что это НЕ запуск из бутлоадера и надо именно не рушить состояние и сделать трансфер оного - мы тоже подумаем потом видимо. А задним то умом все крепкие. Когда фичу за вас уже запилили - тогда просто. > Хоть в файл, хоть в другую область памяти, хоть куда. Как говорится, было просто на бумаге, да забыли про овраги.
	Ответить \| Правка \| К родителю #7 \| Наверх \| Cообщить модератору


	49. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..."	+1 +/–
	Сообщение от OpenEcho (?), 15-Апр-25, 15:20
	> Может это потому, что они юзают си, где нет ооп в явном виде. Каждый раз думаю, все, хорош читать коменты на опеннете, но блин, ради таких генальных комментов можно и подсесть :)))
	Ответить \| Правка \| К родителю #7 \| Наверх \| Cообщить модератору


	54. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..."	+1 +/–
	Сообщение от Аноним (54), 15-Апр-25, 17:29
	Троллите, или вам просто лень посмотреть на реализацию сохранения и загрузки объекта? Нихрена там не тривиально, особенно с методами. По сути нужно чуть ли не ELF-файл дампить, чтобы потом обратно ваш "объект" загрузить.
	Ответить \| Правка \| К родителю #7 \| Наверх \| Cообщить модератору

11. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..."	+/–
Сообщение от Аноним (11), 15-Апр-25, 10:24
А можно написать команду как меняется переход то?
Ответить \| Правка \| Наверх \| Cообщить модератору

19. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..."	+/–
Сообщение от Аноним (19), 15-Апр-25, 10:54
Такое уже было и даже в нескольких видах. И умирало потому что особо никому не нужно было. На самом деле "когда остановка недопустима и необходимо обеспечить непрерывный цикл работы отдельных устройств." _очень_ узкая прослойка, сходу даже и не скажешь, где нельзя остановиться, но, где прям кровь из носу, нужно зачем-то обновиться.
Ответить \| Правка \| Наверх \| Cообщить модератору


	23. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..."	+/–
	Сообщение от Аноним (23), 15-Апр-25, 11:16
	При чём тут "нельзя"? Просто зачем делать перебой, если его можно не делать?
	Ответить \| Правка \| Наверх \| Cообщить модератору


	55. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..."	+1 +/–
	Сообщение от Аноним (54), 15-Апр-25, 17:31
	Решается покупкой второго компьютера и использованием системы с передачей управления в него от выключаемого. Другой вопрос, почему перезагрузка вдруг стала "дорогой", медленной операцией.
	Ответить \| Правка \| Наверх \| Cообщить модератору

27. "Механизм Kexec HandOver для перезагрузки ядра Linux без поте..."	+/–
Сообщение от Аноним (27), 15-Апр-25, 11:34
Как по мне это все костыли для монолитного монстра. Нужно сохранять состояния системы, для того что бы обновиться в рилтайм? Используйте QNX или другие системы с модульным микроядром. А если уж приспичело обновлять монолитное ядро то реализацию нужно возлагать на разработчиков модулей и софта, а не патчи придумывать ... Взгляд с другой стороны
Ответить \| Правка \| Наверх \| Cообщить модератору