LINUX.ORG.RU

Система разработки ядра Линукса даёт сбои


0

0

Второй человек в Линуксе, Andrew Morton, горько сетует по поводу состояния разработки -mm ветки ядра (напомню, что именно в неё сначала добавляются добавляются экспериментальные патчи, а только потом, после тестирования они имеют шанс попасть в основное ядро): "У меня ушло двое полных суток на то, чтобы всё это скомпилировать и загрузить на нескольких моих компьютерах. Чтобы добиться положительного результата в этом процессе, я написал около девяносто исправляющих патчей и патчей по отбрасыванию ненужного. Уже сейчас я наблюдаю несколько известных мне багов, но, полагаю, на самом деле, их гораздо больше. Я должен сказать, что [такая модель разработки] больше не работает." Последний патч для ядра 2.6.23-rc6 весит почти 30 мегабайт. По русски говоря, это около тридцати тысяч страниц исходников (если оптимистично считать по тысячи символов на страницу).

В продолжении, на вопрос об очередном патче, он пишет: "С меня довольно, пускай этим займётся Greg". Определенно, ресурсов одного человека не хватает для столь тяжёлой и ответственной работы.

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

★★★★★

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

ЯПАЦСТУЛОМ. Ай молодец, рассмешил.

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

Как бы не силен насчет вима. Емакс очень даже катит под иде. Неудобно - перепишите хоткеи как вам надо, и все дела. Лисп однако. Плагинов до черта, и не тормозит. Перлы, пыхпы, питоны, очумиэли, иксемели,эскуели и прочую байду можно писать и отлаживать из под емакса. Следует заметить что ни один из более менее вменяемых проектов невозможно написать на одном языке, к примеру менять редактор для того чтобы написать к сишной проге доку влом. А разметку теха в делфишном редакторе - править не удобно.

Более того современные "программеры" почему то думают что програмирование это таскание контролов с панелки на форму. Ну в этом случае дельфи, конечно же, крут. Я лично подозреваю что для программирования нужен эта, как его.... Мосск. А поскольку программа всего лишь баальшой и непонятный текст, то собсно основной инструмент программера - хороший текстовый редактор.

>>Так что согласен что в начале надо разработать удобный и функциональный отладчик...

Черт возми! Народ с кернел орг ладят сурсы хреновым и неудобным отладчиком. Надо срочно открыть им глаза! Нужен, оказывается, удобный отладчик. А мужики-то не знают.

ЗЫ Манов почитайте что-ли.

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

>> Мой вопрос предельно конкретный: в каких ОС используются более двух колец защиты? > Multics, OS/2

А нетварь она часом не из этих ли тоже была?

HEBECTb_KTO
()

На мой взгляд,нужно _гибридное_ ядро, не чистое микро. Гибриды бывают разными, есть и высокоэффективные. Посмотрите на AmigaOS, например. До сих пор нет системы, более бережно управляющейся с ресурсами. Да, там нету многих современных фишек, вроде защиты памяти, но если взглянуть на это трезво - насколько они нужны ? Ядро Линуса же, по сравнению с ними всё больше напоминает мастодонта. При такой тенденции применения в десктопных системах, эта структура начинает непомерно расти. Не знаю, каков Hurd, но думаю, стоит посмотреть

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

> Я бы с радостью помог микрософту (чёрту, кому угодно), чтобы XP заработала на одной из моих китайских материнок со включенным в биосе apic.

Хм, нешто у вас и в самом деле такие проблемы _в виндовсе_? А я-то гадал, кому в том треде анонимус посоветовал на солярку пересаживаццо :-)

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

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

Защита памяти, мягко говоря, нужна.

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

Разделение разработки на 2 ветки (сервер/десктоп) просто нереально. У той же виндовс во всех системах ядро - одно и тоже. Любая среднестатистическая машинка с п4 имеет ресурсов в избытке и упрощать ядро смысла не имеет вообще.

Sun-ch
()

как уже верно заметили, нужно было отделить некоторые виды дров в отдельные проекты, примерно как сделано с алсой. И оставить в ядре только поддержку дисковых контроллеров, сетевух и самого необходимого. А всякое алса, осс, v4l, всякие УСб гаджеты и прочую фигнотень выкинуть в отдельные проекты и распространять отдельны тарболом

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

До сих пор с успехом обходились без защиты, при этом программирование упрощалось, скорость работы увеличивалась. Не стоит воспринимать это с позиций Linux/Windows. ps 64х-битный порт AROS (OSS AmigaOS) будет иметь основные функции защиты. В дальнейшем они будут бэкпортированы на остальные порты и будут развиваться.

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

>Любая среднестатистическая машинка с п4 имеет ресурсов в избытке и упрощать ядро смысла не имеет вообще.

Интересно вообще, если так будет думать каждый разработчик, этих ресурсов очень быстро не станет..=\

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

> Кстати, а что мешало бы их графике сидеть, скажем в 1м кольце вышеупомянутого 386-совместимого камня?

В первую очередь то, что четыре кольца защиты у x86, у большинства других камней - только два, а M$ пока ещё пытается сохранить претензии на не x86-only...

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

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

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

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

Как вы лихо отсеяли необходимое... :) Некоторым, например, дисковая подсистема не является необходимой. А для некоторых - usb обязательна.

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

> До сих пор с успехом обходились без защиты

В DOS, представьте себе, тоже. Желающие развивать ядро на базе FreeDOS есть? ;-)

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

>как уже верно заметили, нужно было отделить некоторые виды дров в отдельные проекты, примерно как сделано с алсой. И оставить в ядре только поддержку дисковых контроллеров, сетевух и самого необходимого. А всякое алса, осс, v4l, всякие УСб гаджеты и прочую фигнотень выкинуть в отдельные проекты и распространять отдельны тарболом

для этого нужно, чтобы API и интерфейсы были стабильными, чего сейчас нет

anonymous
()

Пора переходить на haiku?

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

anonymous> Фря - наиболее продвинутая и универсальня *BSD.

Фряха - труп ходячий.

anonymous> А всякие форки типа MirBSD DragonflyBSD Debian etc можно вобще не рассматривать.

Ты точно дебил. DragonFly BSD - единственная перспективная, дубина.

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

> В первую очередь то, что четыре кольца защиты у x86, у большинства других камней - только два, а M$ пока ещё пытается сохранить претензии на не x86-only...

У каких камней? Для микроконтроллеров есть Windowzz-CE. Микролинукс тоже есть какой-то. А то, конечно, давайте сидеть в каменном веке ориентируясь на самые отсталые технологии. Только блин теперь уже не только линукс, но и система его разработки даёт очевидные сбои, которые становится всё труднее прятать от огласки.

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

> Как вы лихо отсеяли необходимое... :) Некоторым, например, дисковая подсистема не является необходимой. А для некоторых - usb обязательна

Но ещё обязательнее куча финтифлюшек в /sys и /proc

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

> Как вы лихо отсеяли необходимое... :)

>Некоторым, например, дисковая подсистема не является необходимой. А для некоторых - usb обязательна

>Но ещё обязательнее куча финтифлюшек в /sys и /proc

на самом деле всем драйверам к конкретным железкам место в отдельных проектах. В главном, же должны быть vm, vfs, schedulers и тому подобное. Так глядишь и к стабильному API можно прийти.

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

У мастдая микроядро?

Можно ссылочку на это утеврждение? Впервые встретил на лоре, честно говоря. У них ядро, а не микроядро. И попытка вынести графику была именно из ядра. Но у них такое тормознутое поделие получилось, что им самим страшно стало и никто не покупал. И они запихали графику обратно в ядро. Тормозит с тех пор поменьше, конечно. Но это не меняет того, что у мастдая не микроядро )

AndreyKl ★★★★★
()

>Pleeeeeze do try to cc the appropriate developer(s) and mailing lists when reporting problems, thanks.

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

Вот это самое "пожааалуйста" и улыбнуло, грустно так улыбнуло. Это как же человека все достало...

>Just for fun, понимаешь

>eg0_dist0rti0n * (*) (19.09.2007 10:20:50)

Тут ты прав. "Fun", который все так долго ждали, таки наступил.

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

> У каких камней?

Например, у PowerPC. Ещё на Alpha были. У меня нет точного списка. Но 4 кольца защиты - это далеко не правило.

> А то, конечно, давайте сидеть в каменном веке ориентируясь на самые отсталые технологии.

Это не отсталые технологии. Это старый боян. Больше двух колец защиты актуально для микроядер. Но для микроядер больше криков. Если сейчас хватает проблем при переключении контекстов user space-kernel, то ещё будут лаги при переключении kernel-drivers. Вам оно надо?

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

> У мастдая микроядро?

Было. Когда они только начинали разрабатывать NT (ещё 3.x) у них пришла толковая команда и они хотели действительно обеспечить себе технологическое превосходство. Ядро NT делалось микроядерным. Но ближе к релизу выяснилось, что оно безобразно тормозит (особенно подсистема ввода-вывода). Тогда его оперативно переделали в гибридное, но всю линейку NT 4.x за ним тянулась частичная микроядерность. В Win2k ядро снова переделали в монолитное.

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

>Подсистема Win32 и оконная система в режиме ядра. Классное микроядро.

И все таки это никак не монолитное ядро. 1. Драйвера крутятся не в адресном пространстве основного микроядра (здесь и далее "микроядра винды"). 2. Так же в функции микроядра не входят операции ввода/вывода. 3. сетевая подсистема (как, впрочем, и куча других подсистем) также не в микроядре.

и т.п.

Так что, все еще монолитное? ;^]

>Учу постоянно. А ты задай в гугле "Cutler NT microkernel", узнаешь много нового.

Я предпочитаю новое узнавать из книг.

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

>Можно ссылочку на это утеврждение? Впервые встретил на лоре, честно говоря. У них ядро, а не микроядро. И попытка вынести графику была именно из ядра. Но у них такое тормознутое поделие получилось, что им самим страшно стало и никто не покупал. И они запихали графику обратно в ядро. Тормозит с тех пор поменьше, конечно. Но это не меняет того, что у мастдая не микроядро )

Наличие графики в ядре не говорит о том, что оно стало монолитным. В Линухе графика не в ядре, но Линух - монолитен. Эти два понятие вообще не связаны.

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

>. В Линухе графика не в ядре, но Линух - монолитен. Эти два понятие вообще не связаны.

Ну и где же "графика в Линухе"?

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

> И все таки это никак не монолитное ядро. 1. Драйвера крутятся не в адресном пространстве основного микроядра (здесь и далее "микроядра винды").

Во всех виндах линейки Win9x и NT 3.1-XP драйверы железа были в ядре. Насчет Висты - не знаю.

> 2. Так же в функции микроядра не входят операции ввода/вывода.

Тебе что-нибудь говорят слова NT IO Manager? По книге Кастер, "диспетчер ввода/вывода"..

> 3 сетевая подсистема (как, впрочем, и куча других подсистем) также не в микроядре.

Тот же ответ, что на 1.

>> А ты задай в гугле "Cutler NT microkernel", узнаешь много нового.

>Я предпочитаю новое узнавать из книг.

Почитай Хелен Кастер ("Inside Windows NT" не помню, как перевели название на русский).

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

> Вот и о ком в конечном итоге думают разработчики ядра?

О себе. Почему они должны думать о вас?

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

dikiy> Линух - монолитен

У него имеются модули, следовательно он не монолитен.

Led> Ну и где же "графика в Линухе"?

В ядре, но её оттуда легко удалить (вырубаем Frame Buffer ;) ). И то эта графика не используется в повседневной жизни - как графическая подсистема используется X11.

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

> а что, кто-то пытался что-то спрятать? :-)

А что, так часто можно встретить линуксоида, способного спокойно, без демагогии и наездов на оппонента воспринять информацию о том, что линукс далеко не так стабилен как виндовус? Если бы не ряд публикаций, некоторые товарищи тут бы просто на говно исходили бы доказывая безбажность линукса и что разработка линукса идет правильным путём под верным руководством мудрых товарищей ;-)

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

А у вас есть подобная информация от самих разработчиков по Винде, чтобы было что сравнить, или нет? Вспомните как пример WinFS например. Был и вдруг помер.

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

Вооющето есть реализации графика в ядре, консоль в ядре. Новость на opennet.ru была. Сейчас ссылок найти не могу. Сссори.

yantux
()
Ответ на: комментарий от Quasar

>> Led> Ну и где же "графика в Линухе"?

> В ядре, но её оттуда легко удалить (вырубаем Frame Buffer ;) ). И то эта графика не используется в повседневной жизни - как графическая подсистема используется X11.

На что и намекалось:)

Кстати, drm, nvidia.ko можно считать "графикой в Линухе"? Дык, ото тоже как бы в ядре.

Led ★★★☆☆
()

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

Ну code coverage делают, скрипты для systemtap'а пишут, в конце концов, printk в нужных местах расставляют. Вот то-то им хорошо заживётся, когда придут программисты с ВисуалС и покажут им, как нужно драйвера из ВисуалС отлаживать!

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

> На мой взгляд линукс сообщество в первую очередь должно разработать подчеркну УНИВЕРСАЛЬНЫЙ web интерфейс управления настройками системы,

вообще есть webmin, но универсальный с большими комментариями text гораздо удобнее.

vadiml ★★★★★
()
Ответ на: комментарий от Sun-ch

> А интересно, как твой многомудрый мозг отловит race conditions

Включит отладку блокировок в ядре (речь, надеюсь, ещё про ядро?), напишет stap-скрипт.

mv ★★★★★
()

И все-таки, ЛОР рулит. ;) Для сравнения, как подана сия новость на http://www.opennet.ru/

>Andrew Morton, мантейнер экспериментальной ветки Linux ядра "-mm" в которой производится первичная обкатка всех новых патчей, сообщил в списке рассылки разработчиков Linux ядра, о том что уже не в силах обрабатывать нынешний объем патчей.

>Так файл изменений (diff) между основной веткой 2.6.23-rc6 и экспериментальной 2.6.23-rc6-mm1 составляет 29 Мб. Только на состыковку всех новых патчей и сборку ядра у Andrew ушло два дня. При этом было внесено около 90 исправлений, но скрытых ошибок существует гораздо больше. Эффективность "-mm" ветки, как инструмента для обкатки новых патчей не оправдывает себя.

>Некоторые разработчики предлагают составить черный список людей присылающих некачественные патчи, и затем отстранить их от процесса азработки. Andrew единственным выходом видится привлечение мантейнеров >подсистем ядра к процессу первичной обработки патчей.

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

> Зачем интелу четыре кольца защиты по-твоему в 86й архитектуре?

шоб было

а вообще в 80286 их 2 потом стало 4 а в x86_64 amd опять сделала 2

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

> Зачем интелу четыре кольца защиты по-твоему в 86й архитектуре?

4 кольца там очень давно. Ещё с 386. А может и раньше. Про 286 я уже не помню. :) Сделали их как задел на будущее, думали, что это решит много проблем и т.д. На деле всё съедали накладные расходы.

> И ты думаешь, они нигде не используются, раз они не используются в виндоусе и линуксе?

Используются. В специальных системах. Там, где ради надёжности можно пожертвовать и переносимостью и быстродействием.

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

>У него имеются модули, следовательно он не монолитен.

Бред. У ядра единое адресное пространство. Модули тут ни при чем.

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

>о всех виндах линейки Win9x и NT 3.1-XP драйверы железа были в ядре. Насчет Висты - не знаю. >Тебе что-нибудь говорят слова NT IO Manager? По книге Кастер, "диспетчер ввода/вывода"..

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

>Почитай Хелен Кастер ("Inside Windows NT" не помню, как перевели название на русский).

Не интересно. Я имел в виду книги по принципу строения ОС (винда, как таковая, меня меньше всего интересует). Например William Stallings "Betriebssystemen und Umsetzung" (как это по английски - не знаю).

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

> На деле всё съедали накладные расходы. Где они съедали всё? Пальцем покажи. Тебе вон сколько наименований вполне дееспособных систем выше привели, а ты всё бубнишь, что процессору трудно контексты переключать. В 90х было не медленно, а сейчас с охеренными кешами под дескрипторы на борту - и ваще насрать. Просто это должно быть микроядро, а не свалка всякого глючного мусора на всякий случай.

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

> Может пора Линусу задуматься и о стабилизации интерфейсов?

уже думал, решил что вреда больше чем пользы.

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

> То, что оно крутится в пределах одного с микроядром кольца ни о чем, по большому счету, не говорит.

Ага. Единственное о чем это говорит, так только о том, что это - не микроядерная архитектура.

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

> Если сейчас хватает проблем при переключении контекстов user
> space-kernel, то ещё будут лаги при переключении kernel-drivers.
> Вам оно надо?

И это не считая того что всякие сервисы типа "файловые системы" и "сетевая система" могут быть вынесены в отдельные сервисы и на один вызов типа user space-kernel могут приходится несколько вида kernel process 1 - kernel process 2

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

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

Ага. Вот так же думали авторы наноядер :) Они уменьшили по максимуму оверхед на посылку сообщений и засунули свое наноядро в кеш.

Только упростить его пришлось по самое небалуйся и получившиеся интерфесы стали напоминать того самого сферического коня в вакумме.

И для работы с которыми понадобилось сильно менять/приспосабливать остальные ядерные процессы/сервисы. Вследствие этого получившиеся ОС-киты до сих пор находятся в лабораториях.

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

>Ага. Единственное о чем это говорит, так только о том, что это - не микроядерная архитектура.

Больше микроядерная, чем монолитная. Это гибридная вообще-то. Но к микроядру намного ближе.

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

>>Почитай Хелен Кастер ("Inside Windows NT" не помню, как перевели название на русский).

>Не интересно. Я имел в виду книги по принципу строения ОС (винда, как таковая, меня меньше всего интересует)

То есть книгу ты не читал, но она тебе не интересна. "Это многое объясняет" (c)

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

> Только упростить его пришлось по самое небалуйся и получившиеся интерфесы стали напоминать того самого сферического коня в вакумме.

Какие интерфейсы вам нужны у ЯДРА??? "Дай ресурс" да "забери ресурс" - вот и все его интерфейсы.

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