LINUX.ORG.RU

Релиз стабильной версии realtime-ядра Linux 2.6.34-rt

 , , , ,


0

0

Состоялся релиз стабильной версии ядра Linux, модифицированного для использования в системах реального времени. Это ядро используется в промышленных дистрибутивах MontaVista, Red Hat и Novell.

На данный момент ядро -rt содержит около пятисот патчей, накладываемых поверх основного ядра. С момента выхода 2.6.33-rt было внесено более десяти тысяч коммитов. Интересен подход к проблеме тестирования, применённый в процессе подготовки 2.6.34-rt: все десять тысяч коммитов были разбиты на 400 групп, в среднем по 25 патчей в каждом. Далее группы поочерёдно применялись к ядру 2.6.33-rt и тестировались на предмет рассогласований с основными пятьюстами патчами.

Также заслуживает внимания факт постоянного уменьшения количества патчей в ядре -rt в силу перетекания их в основное ядро. Интеграция всех патчей проекта PREEMPT_RT, который и занимается выпуском ядер -rt, может завершиться к концу текущего года или в начале следующего. Вышеописанный метод слияния патчей потребовал всего около двух месяцев на переход от 2.6.33 к 2.6.34. Поэтому, при сохранении таких темпов работы, для интеграции патчей реального времени в ядро 2.6.38 потребуется около восьми месяцев.

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

Ответ на: комментарий от cvs-255

Это реализуется логикой процесса, а не шедулера ОС! Пускай ставит таймер и умирает по его истечению. Но по собственному желанию!

Я не получил ответы про Т-а и lkml, кстати.

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

Еще один не прочитавший про SCHED_FIFO? Если процесс внезапно вытеснить с шедулера --- он неясно когда получит CPU назад --- никакого гарантированного времени не будет.

sv75 ★★★★★ ()
Ответ на: комментарий от cvs-255

А теперь представь, что в ОС, увы, *несколько* процессов, а CPU всего один...

sv75 ★★★★★ ()
Ответ на: комментарий от cvs-255

В общем я понял что либо вы не прочли про SCHED_FIFO, либо клоните к тому, что линукс это не arinc 653. Если второе, то я в курсе, но мне кажется у вас проблемы с первым. Приходите как прочтёте: http://lwn.net/Articles/296419/

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

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

cvs-255 ★★★★★ ()
Ответ на: комментарий от sv75

>Еще один не прочитавший про SCHED_FIFO?

Да неважно когда ваш процесс что-то получит в линухе - ясно что линух ваш не РТ система и точка на этом. Хоть учитайся, а если непонятно - прочитай сам еще раз определение систем реального времени.

anonymous ()
Ответ на: комментарий от cvs-255

Читаем в ARINC-653 про продление deadline, что ли. И про обращение к железу (как я уже раз пять сказал, это крайне плохой пример, поскольку код юзера НЕ ходит к железу).

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

> Да неважно когда ваш процесс что-то получит в линухе - ясно что линух ваш не РТ система и точка на этом.

Спасибо, кэп, но мы были в курсе. А теперь посмотри, что перетирается выше.

Хоть учитайся, а если непонятно - прочитай сам еще раз определение систем реального времени.

Так вот SCHED_FIFO это костыль именно для достижения этого определения.

sv75 ★★★★★ ()
Ответ на: комментарий от cvs-255

> Как пример приведу описанное на лоре чтение поцарапанного cdrom, при котором тормозит мышь.

К сожалению трудно судить о причинах, но тормозит может обработка прерываний. Мне стоить напомнить, что она *не* связана гарантировано каким-либо процессом? Вы всё-таки не читали Таненьбаума, я понял.

Если у нас железо убивает ОС, работа шедулера уже не важна: релтайма не будет.

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

Программа для ЧПУ, обращающаяся к железу через системные вызовы, это уже не код юзера? Системный вызов это та-же библиотечная функция, запущеннная в пространстве ядра.

cvs-255 ★★★★★ ()
Ответ на: комментарий от tailgunner

> Из уважения сделай усилие, чтобы понять.

По-моему тут выходной сегодня по этой части.

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

У тебя вроде звезд дофига и сам не дурак но почему ты пытаешься доказать что черное - это белое, а белое - это черное, я вижу достаточно клоунов - ты один из них ?

anonymous ()

Какой там риалтайм? Аш смешно. Ядро должно быть такое как у QNX.

Сегодня раз десять компилил ядро 2.6.37.2 - работает класс! Всем рекомендую. Ошибок мало. Может пол-года и проживет.

VitS ()
Ответ на: комментарий от cvs-255

В ЧПУ вообще может не быть 1) полноценной ОС 2) нескольких процессов. Это для начала. Второе: читаем про железо в ARINC-653. Третье: если начала работать с железом в Линукс, то процесс наверняка заснул и ждёт его завершения (даже при SCHED_FIFO, да), CPU отдан, все счастливы.

Кстати. Никакого пространства ядра нет. Ну прочтите же Таненбаума, уже надоело.

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

>Ядро должно быть такое как у QNX.

Засунь в жопу свой QNX и никому не показывай - засмеют пиличные люди.

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

> но тормозит может обработка прерываний

ОС реального времени должна при этом при первом же прерывании от таймера, при котором истекло положенное время, сказать «кончаем читать и пишем сообщение об ошибке».

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

В ОС реального времени «положенное время» охватывает активность юзерского кода.

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

> может не быть 1) полноценной ОС 2) нескольких процессов.

А может и быть. Я с таким даже сталкивался. Есть программа пользователя, а есть мониторящая.

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

Да, я надеюсь понятно, что «сообщение об ошибке» в rt --- это обычно синоним слова «катастрофа». Непонятно, почему ты считаешь ОС настолько жестокой. Тем более убивать процесс из-за тормозящего железа (процесс то CPU не занимал!). Хотите уронить самолёт как можно быстрее?

sv75 ★★★★★ ()
Ответ на: комментарий от cvs-255

Это очень сложно ты говоришь. Я лет лет 10 назад такой прессик настроил на одной 16 килобайтной пэзэвухе. До сих пор работает. Зачем усложнять свою жизнь? Может вспомним бритву Оккама?

VitS ()
Ответ на: комментарий от cvs-255

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

К сожалению, основной источник спецификаций на актуальные rt api --- это авиакосмомос. Они же --- потребители.

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

> Тем более убивать процесс из-за тормозящего железа

Кто говорил про убивать процесс? Я не говорил. Я говорил, что если программа вызывает read(), а железо тормозит, то система не пытается пол-часа к нему обращаться, а по истечении некоторого фиксированного времени вернуть сообщение об ошибке. Также я говорил, что если произошло внешнее прерывание от устройства, то оно должно быть обработано не позднее некоторого срока. И еще я говорил, что процессу не должны отдавать все доступные ресурсы, чтобы было возможно реализовать 2 предыдущих пункта

cvs-255 ★★★★★ ()
Ответ на: комментарий от anonymous

Кажется, просто тут одни объясняют, почему в позикс именно SCHED_FIFO — это какбэ rt («процесс сам знает свой дедлайн, не мешайте ему»), а другие пытаются рассказать первым, как же должен работать правильный ARINC-653 (как будто первые не в курсе).

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

>Да, я надеюсь понятно, что «сообщение об ошибке» в rt --- это обычно синоним слова «катастрофа».


Обтекаемые как понос определения - или это катастрофа или это событие будет обработано. Надо бы вам хотя бы обшеобразовательную школу закончить.

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

Я не спорю. Но зачем на кофеварки ставить Линукс?:) Хотя, смотрю в китайскую сторону - дует Линуксом.

VitS ()
Ответ на: комментарий от cvs-255

> Я не говорил. Я говорил, что если программа вызывает read(), а железо тормозит, то система не пытается пол-часа к нему обращаться, а по истечении некоторого фиксированного времени вернуть сообщение об ошибке.

Заметьте, к риал-тайму это вообше напрямую не относится. Это обработка ошибок ввывод-вывода. Потому что проц освобожден.

Кстати, поищите в ARINC-653 read. Как найдёте --- приходите. На сегодня я устал.

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

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

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

> Это обработка ошибок ввывод-вывода. Потому что проц освобожден.

Это относится к реалтайм потому, что другие процессы тоже ввод-вывод хотят

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

1. Если это ввод-вывод на другой устройстве --- это пофиг. Если это же, но оно *умерло* --- тоже пофиг: оно же умерло!

2. С начала флейма обсуждалось планирование CPU.

3. Как я уже писал раз 10, rt озадачено организацией предсказуемого о1тклика при работающем железе. Там и так хватает проблем.

4. Если вы (всё-таки) откроете ARINC-653, вы узнаете много нового об организации ввода-вывода в правильном rt с точки зрения пользователя. Там не как в обычном POSIX, да.

sv75 ★★★★★ ()
Ответ на: комментарий от cvs-255

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

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

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

Хотя врать не буду, может так и есть.

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

> Если это же, но оно *умерло* --- тоже пофиг: оно же умерло!

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

cvs-255 ★★★★★ ()
Ответ на: комментарий от sv75

>что у вас аргументов нет, а вы обычный говнюк-анонимус, таких тут тысячи.

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

anonymous ()
Ответ на: комментарий от cvs-255

> Передача данных по сети в кластере, например.

MPI-кластеры обходятся без рил-тайта.

В современных ПЛ есть сеть, но там будут тоже фатальные неприятности, я боюсь.

Да, канал должен выдержать всех, иначе rt не будет и в случае корректной работы.

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

Читать много доков говорите? И что это даст? Я узнаю, как в некоторых системах этот самый реалтайм реализуется. Но дискуссия то у нас идет не о том, как он где-то реализуется, а о том, что это такое.

cvs-255 ★★★★★ ()
Ответ на: комментарий от KOV

В АН-2 ARIMC-653 нет, я уверен. Смотри на современный истребители, это про них, я думаю.

sv75 ★★★★★ ()
Ответ на: комментарий от cvs-255

Дискуссия была «почему rt в линукс похож на win 3.1»

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

> Да, канал должен выдержать всех, иначе rt не будет и в случае корректной работы.

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

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

Вы узнаете, как устроены rt-os с точки зрения юзера. Это мало, но лучше, чем ничего.

sv75 ★★★★★ ()
Ответ на: комментарий от cvs-255

rt --- не обязательно должна. Если при высокой нагрузке rt нарушался --- надо менять канал.

Блин, читайте ARINC-653, это хотя бы первый шаг от определений к вопросу «как же этого достичь»

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