LINUX.ORG.RU

Проект обновления ядра Linux без перезагрузки получил грант в 100 тыс. долларов

 , , ,


0

0

Компания Ksplice получила от Национального научного фонда США грант в размере 100 тыс. долларов на развитие технологии установки критических обновлений ядра Linux на лету, без остановки работы и перезагрузки системы.

Взято с www.opennet.ru.

>>> Подробности



Проверено: Shaman007 ()

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

>> великий вендокапец... доживу ли я????

наивный

kto_tama ★★★★★
()

Вот это я понимаю

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

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

Надо никогда не делать ошибок, тогда и не надо будет ничего исправлять?)

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

>kexec делать вместо ksplice на каждое обновление безопасности? на ынтырпрайзе то? остановить всё, запустить всё заново. знатная экономия времени, да

По сравнению с кернел паникой - весьма ощутимая.

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

>Я не про текущее положение дел, а про возможно будущее. Я не разбираюсь в структуре ядра, но осмелюсь предположить, что теоретически подобное возможно.

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

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

> > а Вы значит в 5? и утверждаете, что абсолютно не возможно поменять "структуру" на лету?

> домыслы, домыслы. найдите, где я что-то подобное утверждаю

Смотрите, я утвержаю. ;-)

Далее если кому не понятно поясню. В момент выполнения программы ваша "структура" представляет из себя: 1. N кусков памяти размазанных по ОЗУ/swap. 2. M кусков кода для работы с этими данными 3. K кусокв кода с инициализацией этих кусков данных. 4. L кусков кода/данных на которые есть указатели из этих стуктур.

Циклопичность задачи полного обновления ядра на лету умножается на Z сочетаний версий ядра и обычных патчей + сочетание нового ядра со старым, не в курсе дела, USER-space + зацикливание цепочек по типу list. N*M*K*L*Zю = оно кому надо? Мне уже страшно если представить передачу сокетов с их буферами или FD с фильмом в HDTV.

Проще сделать стандартный интерфейс передачи внутренних настроек между ядрами старым в suspend и новым в configuring. В каждый модуль [Un]Serialise и усё.

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

> А на лету заменить одни модули на другие это не проблема.

Очень легкомысленное заявление, учитывая требование беспрерывной работы USER-space.

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

>...Циклопичность задачи полного обновления ядра на лету умножается на Z сочетаний версий ядра и обычных патчей + сочетание нового ядра со старым, не в курсе дела, USER-space + зацикливание цепочек по типу list. N*M*K*L*Zю = оно кому надо? Мне уже страшно если представить передачу сокетов с их буферами или FD с фильмом в HDTV...

:-) т.е. все-таки решаема задача

вопрос только в том, что бюджет сильно маловат для этого

Guest30
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.