В трекере ошибок ядра в настоящее время накопилось (http://www.linuxworld.com/news/2007/091207-kernel.html) около 1500 нерешенных проблем, 50 проблем ожидают первичного рассмотрения.
Процесс исправления ошибок нуждается в оптимизации. Andrew Morton предлагает учредить должность "bugmaster" для помощи в рассмотрении сообщений об ошибках, доведения информации до конечного разработчика и контроля за исправлением.URL: http://www.linuxworld.com/news/2007/091207-kernel.html
Новость: http://www.opennet.me/opennews/art.shtml?num=12007
Мы тоже не успеваем... и в федоре тоже... и в opensuse, помнится, тоже... и в дебиане -- тоже тоже...Но пойманная и зафиксированная в багтрекере ошибка -- всё равно гораздо лучше, чем сообщение в список рассылки, лично разработчику или высказанное потолку и шторам :)
Мортон, разумеется, прав -- по-хорошему, BTS заметного проекта такие люди жизненно нужны, как и секретари-референты заметным конторам.
в ядро ежедневно вносится масса модификаций и зачастую получается что исправляя одну проблему они пораждают три - четыре других. это вполне естественно при таких объемах монолитного строительства.
>в ядро ежедневно вносится масса модификаций и зачастую получается что исправляя одну
>проблему они пораждают три - четыре других. это вполне естественно при
>таких объемах монолитного строительства.Да когда же все повторятели слова "монолитный" применительно к ОС пойдут и исправят все-все проблемы и функциональные недостатки профессорского поделия? Например, чтоб драйвер tty хоть перезапускался, если его кильнуть.
И ещё и так, чтоб при этом усложняющееся в геометрической прогрессии взаимодействие между серверами не привело к возникновению трёх-четырёх десятков проблем взамен.
если возникает необходимость "убивать" tty - использования монолита - не лучший выбор. может тогда в сторону qnx посмотреть? они кстати исходники выложили.. возможно в недалеком будущем увидем некоторые измения в ядре линукса ^_^
p.s. одни создают - другие пользуются.
>если возникает необходимость "убивать" tty - использования монолита - не лучший выбор.[beep]. Я про Minix3, если Вы вдруг тоже ещё не проснулись.
>может тогда в сторону qnx посмотреть? они кстати исходники выложили..
Hint: выложили вовсе не от того, что техническая и бизнес-модель побеждает. Хотя это как раз скорее огорчает, продукт интересный и лавка явно интересная.
>p.s. одни создают - другие пользуются.
_Пользуются_, а не высказывают своё высочайшее мнение по архитектуре. Или таки шлют патчи.
На высказывание не стоит тратить ни своего, ни чужого времени -- а то ведь ещё менее опытные могут и купиться на, гм, неправду, потом и получается, что "всё знаем", ничего не делая.
Интересно, почему у меня в Minix отваливается сетевое подключение ethernet при простое? Может я глупый или напильник устаревший :)?
>И ещё и так, чтоб при этом усложняющееся в геометрической прогрессии взаимодействие между серверами не привело к возникновению трёх-четырёх десятков проблем взамен.Когда увидел этот опус, сразу дежавю ощутил... Где же я это уже видел? Точно, в книжке Торвальдса "Just for Fun". Там он отжигал про "человеческий мозг" и "усложнение взаимодействия в микроядре":
"Мне это казалось глупым. Да, каждая отдельная часть получается простой.
Но при этом их взаимодействие становится гораздо более сложным, чем при
включении ряда сервисов в состав ядра, как это сделано в Linux. Представьте
себе человеческий мозг. Каждая его составляющая проста, но их взаимодействие
превращает мозг в очень сложную систему. В этом-то все и дело: целое больше
частей. Если взять проблему, разделить ее пополам и сказать, что каждая
половинка вполовину проще, то при этом вы игнорируете сложность интерфейса
между половинками. Сторонники микроядра предлагали разбить ядро на пятьдесят
независимых частей так, чтобы каждая часть была в пятьдесят раз проще. Они
умалчивали о том, что взаимодействие между частями окажется сложнее исходной
системы -- при том, что и части сами по себе не будут элементарными.Это самое главное возражение против микроядра. Простота, обеспечиваемая микроядром, является мнимой."Так вот, исходники Minix3 (с КОММЕНТАРИЯМИ) помещены в книгу (в русском издании на CD), и их вполне можно ЧИТАТЬ и досконально изучить за семестр. Представляете себе исходники ядра линукс (пусть даже самые базовые, без драйверов), помещенные в книгу? Да там черт ногу сломает. И человек, видивший исходники Minix3 и Linux никогда не согласится с тем, что "Простота, обеспечиваемая микроядром, является мнимой". И сравните время компиляции Minix3 со всеми утилитами и голого ядра линукса. Да, оно гораздо функциональнее, однако оно по устройству своему сложнее. В любом случае, развитие всех современных ОС так или иначе движется в сторону микроядра, даже в линуксе уже заходят разговоры о необходимости стандартизации API драйверов и перенос некоторых их них в user space. Так что Линусу скоро будет стыдно за все эти выкрики, которые он делал по молодости. А идиотам, орущим в свое время "Таненбаум - старый маразматик" уже ничего не поможет, даже когда Linux в конечном итоге микроядерным станет, мозгов у них не прибавится.
>>И ещё и так, чтоб при этом усложняющееся в геометрической прогрессии взаимодействие
>>между серверами не привело к возникновению трёх-четырёх десятков проблем взамен.
>Когда увидел этот опус, сразу дежавю ощутил... Где же я это уже
>видел? Точно, в книжке Торвальдса "Just for Fun".Именно. А у меня было дежавю, когда этот кусок читал -- поскольку там было обёрнуто в слова то ощущение, которое возникло от "исторического спора".
>"Простота, обеспечиваемая микроядром, является мнимой."
>Так вот, исходники Minix3 (с КОММЕНТАРИЯМИ) помещены в книгу (в русском издании
>на CD), и их вполне можно ЧИТАТЬ и досконально изучить за семестр.Дальше-то что? Счётные палочки тоже можно досконально изучить за старшую группу ползункового отделения. Вот только сами палочки потом бесполезны, а навыки претерпевают множество трансформаций для того, чтобы стать полезными. При этом таки да, становясь не передаваемыми непосредственно оной группе.
(домашнее задание: рассчитаться за покупки наличностью с применением палочек при проверке сдачи)
>Представляете себе исходники ядра линукс (пусть даже самые базовые, без
>драйверов), помещенные в книгу?И "Apache в комментариях" тоже представляю, но вообще-то Understanding the Linux Kernel -- обычный талмуд несколько тяжелей APUE, а что? (это не листинг, а объяснение более высокоуровневым языком, чем C -- английским; плюс индекс по исходникам)
>И человек, видивший исходники Minix3 и Linux никогда не согласится
>с тем, что "Простота, обеспечиваемая микроядром, является мнимой".Покрутив Minix3 в руках, меня уже совсем не тянет ещё и в его исходники смотреть. Даже не потому, что оно попросту не годится ни для одной из тех задач, что у меня есть (включая образовательные, но не для системщиков). Я не вижу в этом смысла, а учебные ядра есть и другие -- AtheOS, например.
Заметьте, Вы упёрлись в простоту исходников, а я -- в простоту результата, поскольку исходники ради исходников или даже обучения людей, которые будут яро верить в примитивность вместо простоты, а не создавать умные или хотя бы работающие проекты -- не интересуют, как вот тяжмаш ради тяжмаша.
И здесь надо уметь преподать учебное -- как учебное, без претензий на свою правоту "в большом мире"; иначе выходит не столько наука, сколько обман. Именно здесь и была проблема у профессора.
>И сравните время компиляции Minix3 со всеми утилитами и голого ядра линукса.
>Да, оно гораздо функциональнее, однако оно по устройству своему сложнее.Это почти тавтология, ну да кто бы спорил.
Я уже почти зарёкся общаться с иными неофитами, дистрибутив которых "устанавливается в пять минут" и "содержит ВСЁ нужное вам" -- это теперь "узелки на память" для быстрого установления диагноза. Так вот и про время компиляции, наверное, уже скоро узелок придётся завязать -- оно важно для гентушников, майнтейнеров и примитивистов, причём у первых двух групп резона обычно всё-таки больше.
>В любом случае, развитие всех современных ОС так или иначе движется в сторону микроядра,
Можно пальцем указать?
NT -- уходит от микроядра, хоть и современная с натяжкой.
OSX -- сидит, впрочем, чуточку зная Джобса -- как только оно ему помешает прикрутить финтифлюшку, будет выкинуто точно в той же пропорции, как и Гейтсом после NT 3.51.
QNX -- пока скорее не развивается, а завивается, как ни жаль.
Solaris -- не наблюдаю такого вообще.Про Linux речь и так вот, а ведь это претензия на пост-UNIX, которую сложно оспаривать (OpenSolaris мож сможет -- если сани поймут, как _эффективно_ работать с сообществом и что никому особо не нужен халявный юникс, который разрабатывается закрытой кучкой, и претворят это понимание в жизнь).
>даже в линуксе уже заходят разговоры о необходимости стандартизации API драйверов
>и перенос некоторых их них в user space.В линуксе не разговоры заходят, а давным-давно куча всего работает или отдельными kthreads, или именно что юзерспейсными процессами. Никакой фанатической позиции по поводу "да это же так, как профессор говорил, а он лох!" -- не наблюдал. Скорее золотая середина -- где разумно/работает, там вытаскивается, где неразумно или не работает (см. скипнутую цитату) -- там нет.
>Так что Линусу скоро будет стыдно за все эти выкрики, которые он делал по молодости.
Вообще-то, наверное, каждому разумному человеку бывает стыдно за выкрики, которые он делал по молодости -- но Линус-то с Таненбаумом уже давно успели перетереть по поводу старых флеймов (удивительно культурных по современным меркам), дружески сфотографироваться в обнимку и согласиться, что у них разные подходы к архитектуре ОС.
Заметьте, имена иных учеников, которых иные преподаватели отбрасывали (и которые стали в своём роде краеугольными камнями) -- известны лучше имён этих самых преподавателей. Эдисона вон тоже из школы выперли "за тупость" -- не припомните, кто именно?
Поэтому я тут даже скорее за Таненбаума рад -- старшему-то сложнее.
>А идиотам, орущим в свое время "Таненбаум - старый маразматик" уже ничего не поможет
Вы перечитайте прогнозы Таненбаума про "everyone will be running...", потом сравните со своими и мож подумайте, что сказать-то хотели, пока не забыли? :]
>даже когда Linux в конечном итоге микроядерным станет, мозгов у
>них не прибавится.Конечно, не прибавится -- как правило, это уже люди за двадцать и вес головного мозга стабильный -- или ему уже и уменьшаться потихоньку время пришло, бо за тридцатник.
Я же рискну поставить (на LF20?) ящик черниговского против Вашего имени, что мои оракулские (или аналитические :) способности попрактичней будут -- бишь Linux ни в каком конечном итоге микроядерным не станет, к этому попросту нет предпосылок (включая single-image massive multiprocessors). Если LKML или ещё кто вдруг найдёт решение для проблемы взаимодействия -- то это будет как минимум не линукс, а другой фромскратч, который только взлетать будет ещё несколько лет. _Если_.
Кстати, самым лучшим способом доказать свою правоту для Вас может оказаться участие в таком поиске. Заодно и насчёт идиотов-маразматиков будет возможность подумать. :)
Disclaimer: я не ядерный разработчик -- так же сознательно, как и решил не лезть в ассемблер, а заниматься прикладными задачами. С тех пор я уже и вообще практически не разработчик, а манагер в нашей фрисофтовой консалтерской лавочке с хобби играться в угадывания таких вот вещей.
до тех пор пока они наконец не заморозят API и перестанут наконец оперировать на открытом сердце и прочих органах, будет наблюдаться этот хаос.
>до тех пор пока они наконец не заморозят API и перестанут наконец
>оперировать на открытом сердце и прочих органах, будет наблюдаться этот хаос.Ещё один оракул со стажем...
Когда заморозят и перестанут, оно сможет спокойно отправляться на кладбище. Увы, отрасль не в том состоянии, когда можно действительно предсказуемо разрабатывать.
С другой стороны, то, что до сих пор нет ветки 2.7 -- не может не радовать: управление разработкой вместе с самим проектом вышли на уровень, когда необязательно всё перелопачивать и половину разламывать только для того, чтобы что-то добавить.
>Увы, отрасль не в том состоянии, когда можно действительно предсказуемо разрабатывать.чем крупнее архитектура - тем дольше строительство. microsoft тоже в сроки постоянно не попадает.
>С другой стороны, то, что до сих пор нет ветки 2.7 --
>не может не радовать: управление разработкой вместе с самим проектом вышли
>на уровень, когда необязательно всё перелопачивать и половину разламывать только для
>того, чтобы что-то добавить.сколько помню - нечетные ветки всегда шли как unstable или nightly builds.. сейчас ядро 2.6 даже Торвальдс не признает стабильным (о чем он уже ругался в нескольких своих интервью), поэтому смысла и нет в создании 2.7 ветки (unstable vs very-unstable О_О)
>>С другой стороны, то, что до сих пор нет ветки 2.7 --
>>не может не радовать: управление разработкой вместе с самим проектом вышли
>>на уровень, когда необязательно всё перелопачивать и половину разламывать только для
>>того, чтобы что-то добавить.
>сколько помню - нечетные ветки всегда шли как unstable или nightly builds..Какие-такие nightlies, или это не про линукс?
"Правило нечётных=нестабильных веток" -- насколько знаю, линуксового происхождения, вот только и там были версии что в 1.1, что в 2.5.
>сейчас ядро 2.6 даже Торвальдс не признает стабильным (о чем он
>уже ругался в нескольких своих интервью), поэтому смысла и нет в
>создании 2.7 ветки (unstable vs very-unstable О_О)Он не _ругался_. Просто апстрим (LKML) наконец-то пришёл к практическому пониманию того простого факта, что всё равно большинство ядер, которые используются -- вендорской сборки, с вендорскими патчами и вендорским QA. Поэтому kernel.org лучше сосредоточиться на более быстром мерже этих патчей и затыкании тех же дырок, чем вылизывании того, что всё равно соберут аж триста человек на планете, в ущерб более быстрому втягиванию полезного и вытаптывания в нём багов и несоответствий.
А вендоры, со своей стороны, усиленно думают переезжать с бэкпорта новых фич и драйверов на древние "энтерпрайз"-ядра к обновлению базовых версий.
И это очень правильно, как и любое называние вещей своими именами с последующим выравниванием работы по ним.
> до тех пор пока они наконец не заморозят APIDocumentation\stable_api_nonsense.txt
http://www.kroah.com/log/linux/stable_api_nonsense.html
[...]
This is being written to try to explain why Linux does not have a binary kernel interface, nor does it have a stable kernel interface. Please realize that this article describes the _in kernel_ interfaces, not the kernel to userspace interfaces. The kernel to userspace interface is the one that application programs use, the syscall interface. That interface is _very_ stable over time, and will not break. I have old programs that were built on a pre 0.9something kernel that still works just fine on the latest 2.6 kernel release. This interface is the one that users and application programmers can count on being stable.
[...]
> до тех пор пока они наконец не заморозят API и перестанут наконецhttp://liquidat.wordpress.com/2007/07/21/linux-kernel-2623-t.../
Linux kernel 2.6.23 to have stable userspace driver API
Linus Torvalds included patches into the mainline tree which implement a stable userspace driver API into the Linux kernel.
The stable driver API was already announced a year ago by Greg Kroah-Hartman. Now the last patches where uploaded and the API was included in Linus’ tree.
[...]
>до тех пор пока они наконец не заморозят API и перестанут наконецhttp://lwn.net/Articles/162686/
Linux in a binary world... a doomsday scenario
What if.. what if the linux kernel developers tomorrow accept that
binary modules are OK and are essential for the progress of linux.[...]
Может вообще пора отделить разработку ядра от разработки драйверов, создав стабильный API для драйверов?
>Может вообще пора отделить разработку ядра от разработки драйверов, создав стабильный API
>для драйверов?Народ из xorg уже согласился с тем, что это плохо работает, и кивал именно на linux kernel с подходом "то, что in-tree, точно живо, ну или около того".
Ссылку, к сожалению, сейчас искать уже сонный, но сам немного удивился тогда.
Что же касается монолитных ядер/микроядер, то оба подхода имеют право на существование. Однако, желательно и монолитные ядра разбивать на компоненты с четко определенными интерфейсами (например, подсистема управления процессами, подсистема управления памятью, и т. п.), что позволит проводить их тестирование по-отдельности. Если я не ошибаюсь, в Linux тестирование компонентов по-отдельности не производится. При использовании компонентного подхода язык C++ оказался бы лучше C (по крайнем мере, за счет наличия в нем пространств имен, позволяющих скрывать детали реализации).
>Что же касается монолитных ядер/микроядер, то оба подхода имеют право на существование.Однозначно.
>Однако, желательно и монолитные ядра разбивать на компоненты с четко определенными
>интерфейсами (например, подсистема управления процессами, подсистема управления памятью, и т. п.),Вы давно в vm/ заглядывали, btw? Я-то по мере надобности и понимания только в fs/isofs/ ковырялся когда-то, да и то давным-давно как положено исправили...
>что позволит проводить их тестирование по-отдельности. Если я не ошибаюсь, в
>Linux тестирование компонентов по-отдельности не производится.Конечно, и разрабатывается всё в куче -- пришёл человек, ляпнул патч туда, патч сюда, Линус это вместе сгрёб и заработало. :]
Не говоря о тестировании и отчётах по регрессам -- даже бенчмарками совсем никто не балуется, особенно при доказательстве преимуществ нового патча на VM или скедулера процессов/IO.
Все балуются плюшками. И тушью. :)
>При использовании компонентного подхода язык C++ оказался бы лучше C
>(по крайнем мере, за счет наличия в нем пространств имен, позволяющих
>скрывать детали реализации).См. тж. kobjects?
Ну-ну.
Тестирование вещь очень серьезная. И чтобы протестировать нужен талант не хуже програмерского. И к сожалению привлечение только программистов непозитивно. Но - тестировать можно на любом языке, и на С и на С++. Компонентный подход - ну может и поможет. Надо править стратегию, управлять этим процессом некому. Не может Линус управлять этим процессом, не может или не хочет. А вот управленца по лицензии GPL найти наверное невозможно.
Так что скорее всего дело в этом. Надо четко разделять, это пишем, это тестируем, это доводим до кондиции, это в ядро включаем для работы. И все будет хорошо.
>Ну-ну.
>Тестирование вещь очень серьезная. И чтобы протестировать нужен талант не хуже програмерского.
>И к сожалению привлечение только программистов непозитивно. Но - тестировать можно
>на любом языке, и на С и на С++. Компонентный подход - ну может и поможет.Это всё правда.
>Надо править стратегию, управлять этим процессом
>некому. Не может Линус управлять этим процессом, не может или не
>хочет. А вот управленца по лицензии GPL найти наверное невозможно.А это -- феерический бред, простите. Управленцев не ищут "по лицензии", их ищут по умениям и на ставку. Торвальдсу давным-давно изрядно платят аккурат за управление процессом разработки ядра Linux, и у него действительно получается.
>Так что скорее всего дело в этом. Надо четко разделять, это пишем,
>это тестируем, это доводим до кондиции, это в ядро включаем для
>работы. И все будет хорошо.Вот именно так сейчас и поставлено -- деревья индивидуальных разработчиков; ответственных за подсистемы; ответственных за staging tree; ответственных за official tree; поставщиков дистрибутивов.
И всё довольно неплохо ;-)
> См. тж. kobjects?Зачем реализовывать объекты на C, когда можно их использовать на C++, имея поддержку со стороны языка?
>> См. тж. kobjects?
>Зачем реализовывать объекты на C, когда можно их использовать на C++, имея
>поддержку со стороны языка?Зачем тащить весь головняк C++, если можно реализовать нужное на C?
(такой кошмар, как неуправляемое множественное наследование в ядре ОС, мне лично ещё не снился)
Если в языке есть какая-то конструкция, то это не значит, что вы обязаны его использовать.
Я тоже считаю множественное наследование извращением. В природе ведь как, можно конечно скрестить осла с лошадью, но сие творение (мул по моему называется) потомков иметь не может.В этом смысле С++ лишнее подтверждение этому. Для того, чтобы классы с множественным наследованием хоть как-то жили Бъярну пришлось ввести в язык кучу сущностей, которые в обычных языках бессмыслены и бесполезны. И все равно, попытка использовать этот инструмент на этапе проектирования приводит к тому, что при реализации вплывают системные конфликты, которые невозможно было предусмотреть на этапе проектирования.
А с завалами в багтрекере, это нормальное явление. Это говорит о том, что продукт живет и развивается. Было бы странно если бы этого не было, учитывая, что людей, которые были бы материально ответственны за оперативное исправление ошибок нет.
Во многих организациях где есть такие люди, завалы багрепортов тоже обычное явление. Одна 1С чего стоит...
>Если в языке есть какая-то конструкция, то это не значит, что вы
>обязаны его использовать.Да, конечно. Только есть такая штука, как культура около языка и ожидания от проекта, который "на нём" (e.g. "да как же мы без STL" или вообще "без boost"). Думаю, можно погуглить историю плюсового кода в адаптековском драйвере, чтобы выудить мнение разработчиков Linux конкретно о перспективах использования C++ в этом ядре.
>А с завалами в багтрекере, это нормальное явление.
О чём и спич.
Обьекты на С ? Где на С обьекты ? В С обьектов то и небыло. Там можно боком приспособить структуры как дешовую подделку обьектов. Но самих обьектов на С небыло. Не заставляйте меня сомневаться.
У-у-у. Настоятельно рекомендую почитать книгу про компилятор GCC, ну и по С тоже.
Что касается kobject - они пишутся на С, так указанно в книжке Лава "Программирование ядра Линукс"
>Обьекты на С ? Где на С обьекты ? В С обьектов то и небыло._В_ C -- нет, _на_ C -- бывают. Удивлены?
>Обьекты на С ? Где на С обьекты ?А что мешает на сях создавать объекты?