Исходное сообщение
"это не архитектура" Отправлено Michael Shigorin, 25-Май-07 11:37
Поищите по словам "in-tree drivers" и "stable kernel api", тема достаточно изжёванная. Вкратце (и в меру моего чайнического понимания) -- это вопрос не технический ("архитектура ядра"), а организационный ("архитектура управления").  По крайней мере постольку, поскольку ядро и так модульное больше десяти лет, при этом в его развитии участвует гораздо больше компетентного народу, чем в пожалуй что любом другом. Не шибко давно после распила xorg на кусочки (включая драйверы) и опыта разработки/поддержки в таком виде тамошний люд пришёл к подозрению, что "linux kernel got it right" и содержать конкретно драйверы в одной ветке исходников -- сильно менее проблемно при изменениях в инфраструктуре как для обновления кода, так и для отлавливания протухлости оного. А вот утверждений насчёт возможности большей параллелизации разработки тех же микроядер (с исходно относительно простыми модулями, но усложняющимся в геометрической прогрессии взаимодействии по мере роста числа объектов, которым надо уметь общаться) что-то пока не видать.  Подтверждённых практикой.

Ваше сообщение
Имя*:
EMail:	Для отправки ответов на email укажите знак ! перед адресом, например, !user@host.ru (!! - не показывать email). Более тонкая настройка отправки ответов производится в профиле зарегистрированного участника форума.
Заголовок*:
Сообщение*:	> Поищите по словам "in-tree drivers" и "stable kernel api", тема достаточно изжёванная. > Вкратце (и в меру моего чайнического понимания) -- это вопрос не технический > ("архитектура ядра"), а организационный ("архитектура управления"). По крайней мере постольку, > поскольку ядро и так модульное больше десяти лет, при этом в > его развитии участвует гораздо больше компетентного народу, чем в пожалуй что > любом другом. > Не шибко давно после распила xorg на кусочки (включая драйверы) и опыта > разработки/поддержки в таком виде тамошний люд пришёл к подозрению, что "linux > kernel got it right" и содержать конкретно драйверы в одной ветке > исходников -- сильно менее проблемно при изменениях в инфраструктуре как для > обновления кода, так и для отлавливания протухлости оного. > А вот утверждений насчёт возможности большей параллелизации разработки тех же микроядер > (с исходно относительно простыми модулями, но усложняющимся в геометрической прогрессии > взаимодействии по мере роста числа объектов, которым надо уметь общаться) что-то > пока не видать. Подтверждённых практикой.
	Введите код, изображенный на картинке: