В ответ на очередной набор изменений в подсистеме DRM (Direct Rendering Manager), присланный (http://lkml.iu.edu/hypermail/linux/kernel/1702.2/05174.html) для включения в состав будущей ветки ядра 4.11, Линус Торвальдс пришёл в ярость и в жесткой форме раскритиковал (http://lkml.iu.edu/hypermail/linux/kernel/1702.2/05171.html) Дэвида Эйрли (David Airlie), мэйнтейнера подсистемы DRM, за его отношение к контролю качества присылаемых патчей. В частности, Линус недоумевает как мэйнтейнер мог отправить для финального включения в новый выпуск ядра набор патчей, который явно не тестировался и непригоден для сборки из-за ошибки компиляции.
Процесс разработки ядра построен на цепочке доверия и основной задачей мэйнтейнеров подсистем является предварительная проверка и рецензирование изменений в делегированных им областях. По словам Линуса он ожидал лучшего контроля качества, в худшем случае он ожидал хоть какого-то контроля качества, но на деле в присланных изменениях он не увидел контроля качества совсем и предложенные изменения компонента tinydrm (https://github.com/notro/tinydrm) вообще не видели компилятора.В частности при сборке присланного кода компилятором выводилось несколько десятков предупреждений и сборка завершалась ошибкой, изучение которой показало, что код не собирается если модуль backlight не вкомпилируется в ядро, а собирается в виде модуля (CONFIG_BACKLIGHT_CLASS_DEVICЕ=m). Более того, изменение для tinydrm было переотправлено мэйнтейнером на следующий день после получения от конечного разработчика и, судя по всему, без какого-либо тестирования.
В качестве ответных мер на подобное перебрасывание патчей без проверки в последний момент, Линус намерен (http://lkml.iu.edu/hypermail/linux/kernel/1702.2/05174.html) ввести для DRM-подсистемы правило предварительного помещения изменений в ветку linux-next, до открытия окна приёма изменений в очередной выпуск ядра. Таким образом все изменения графических драйверов должны будут вначале быть обкатаны в ветке linux-next, лишь после чего смогут войти в основной состав ядра.То, что в ходе беглого осмотра и простейшего тестирования сборкой выявляется неработоспособность, указывает на серьёзные организационные проблемы. Линус близок к принятию решения о том, чтобы не включать набор патчей DRM в ядро 4.11, чувствуя что кроме него эти патчи никто больше не тестировал. Подобный шаг приведёт к тому, что в состав ядра 4.11 не войдут обновления графических драйверов i915, amdgpu, radeon и nouveau. Так как в настоящий момент приходится отклонять приём всех изменений из набора DRM ("всё или ничего"), Линус намерен потребовать разбения pull-запросов DRM на более мелкие части.
URL: http://lkml.iu.edu/hypermail/linux/kernel/1702.2/05171.html
Новость: http://www.opennet.me/opennews/art.shtml?num=46107
И этим все сказано
И это наше слово (c) BSG
>То, что полная неработоспособность выявляется последней инстанцией в ходе беглого осмотра и простейшего тестирования сборкой, указывает на серьёзные организационные проблемы.Этот горячий финский мужик собственно и создавал базовые правила разработки и интеграции кода.
Почему все замкнуто на него, и почему нет вменяемой группы, занимающейся качеством?
Делать шум это последнее дело, в норме все решаеться качественной огранизацией деятельности.
> Делать шум это последнее дело, в норме все решаеться качественной огранизацией деятельности.Кажется, у нас в гостях очередной успешный менеджер проектов...
>Кажется, у нас в гостях очередной успешный менеджер проектов...Кто бы говорил-на Вашу поделку 1С уже не ставится а вы все тут в камментах умничаете
>>Кажется, у нас в гостях очередной успешный менеджер проектов...
> Кто бы говорилЯ сказал.
> на Вашу поделку 1С уже не ставится
Руки ровняйте, УМВР (не так давно для одного из партнёров как раз проверяли).
> Почему все замкнуто на него, и почему нет вменяемой группы, занимающейся качеством?Досрочный ответ: потому, что большинству просто ложить, им давай уже готовое.
Ударить палец о палец для улучшения чего-то - для них боль.
> Почему все замкнуто на него, и почему нет вменяемой группы, занимающейся качеством?Завидуешь, лузер?
очередной крах менеджмента как системы управления, не более того
>"всё или ничего"Вот она -- монолитность. Жаль что GNU-тое ядро неактивно пилится.
Иди пили, Астал. Мы все будем рады.
Плюсую.Микроядро - единственное РЕШЕНИЕ пролем надёжности Линукса.
И существование GNU/Hurd - доказательство того, что это решение реально.
Этот комментарий следовало бы разделить на два... :)
Зачем?
Чтоб можно было покритиковать по отдельности и Hurd, и предложение микроядрености линукса?
И?Потому и сразу в одном каменте: и необходимость перехода, и его реальная возможность.
Есть другие предложения как решить проблемы надёжности Линуха?
Это был микросарказм :)>Линус намерен потребовать разбиения pull-запросов DRM на более мелкие части.
> Это был микросарказм :)Но набрал он - максимум плюсов :)
> Плюсую.
> Микроядро - единственное РЕШЕНИЕ пролем надёжности Линукса.
> И существование GNU/Hurd - доказательство того, что это решение реально.Ага и широкое её применения на всевозможных устройствах показывает,
что GNU/Hurd мы увидим завтра на наших PC, роутерах и телефонах. Если что это был сарказм.
> Ага и широкое её применения на всевозможных устройствах показывает,
> что GNU/Hurd мы увидим завтра на наших PC, роутерах и телефонах. Если
> что это был сарказм.Сарказм это не страшно. Посмеяться всегда полезно.
И пока кто-то смеётся, кто-то другой уже выпустил 1.5 миллиарда устройств (на 2012 год) на OKL4 микроядре
https://en.wikipedia.org/wiki/Open_Kernel_Labs#cite_ref-3
Да, бывают и другие микроядра, и тоже вполне живые.
> И пока кто-то смеётся, кто-то другой уже выпустил 1.5 миллиарда устройств (на
> 2012 год) на OKL4 микроядре
> Да, бывают и другие микроядра, и тоже вполне живые."General Dynamics is the global leader in virtualization[,,,]
Based on General Dynamics experience helping customers deploy OKL4 in more than 2 billion mobile phones to date, General Dynamics offers a proven path[,,,]"
Славный PR -- нужно бОльше довольных кастомеров.
Но 2млрд венорлоченных тупофонов -- мало! Нужно больше опен-вошь-ных блобов. qnx-то там как, не оскоромнился ещё опенвошками?
+++
""the first phone which employs virtualization to support two concurrent operating systems (Linux and BREW) on a single processor core."" --Пабеда! Где тот Аноним, что хотел?? -- генерал Динамик https://en.wikipedia.org/wiki/Open_Kernel_Labs#OKL4_Microvisor сделал это.
Вы так рьяно доказываете ущербность микроядра, словно это объективная реальность. Вообще-то, микроядро - это математический факт 100% безопасности ОС и ее компонентов.
> Вы так рьяно доказываете ущербность микроядра,Я?? Ты бредишь.
> словно это объективная реальность. Вообще-то,
>объективная реальность
> Вообще-то, микроядро - это математический факт 100% безопасности ОС и ее компонентов.Вас же не затруднит выйти к доске и привести доказательство этого "факта", верно?
А пока https://www.cvedetails.com/vulnerability-list/vendor_id-436/...
> А пока https://www.cvedetails.com/vulnerability-list/vendor_id-436/...Просмотрел первые 10 уязвимостей - это всё о юзер-левеле и "обычном" софте (либы, криво поставленные пермисии).
О самом ядре - ничего нет.
Ты жалок.Твоё микроядро, которое умеет только сообщения между подсистемами пересылать, да переключать процессы, естественно почти неуязвимо. Но это не даёт 100% гарантии безопасности, потому что уязвимости будут в сервисах ОС и в программах, работающих в пользовательском пространстве. Xen - тоже микроядерный гипервизор. И что? Все domU и dom0, работающие под его управлением, автоматически становятся неуязвимыми?
> Твоё микроядроОу, у меня уже есть микроядро. Ссылочку можно напочитать?
> которое умеет только сообщения между подсистемами пересылать, да переключать процессы
> естественно почти неуязвимо.Ну надо же, система неуязвима, но сколько негатива!
Вообще-то, именно это и нужно. Разве нет?
> Но это не даёт 100% гарантии безопасностиАга, как только шаг в непривычную сторону - так сразу вынь-да-положь некие гарантии.
Зато к монолитно-модульной системе никаких претензий по гарантиям нет. Рутовые дыры раз в полгода - но никаких критических каментов.
Двойная логика, видимо, дело привычное.
> потому что уязвимости будут в сервисах ОС и в программах, работающих
> в пользовательском пространстве.Множество "сервисах ОС" полностью принадлежит к "программах, работающих в пользовательском пространстве".
(а где же freehck с критическими выпадами на юзерлевел-пользовательское пространство? Тоже странная такая избирательность за кем замечать, а за кем нет...)Ну ставить ошибки в программах, не относящихся к сервисам ОС, в вину самой ОС и её архитектуре - это занавес (а сам www2, к слову, виноват в том, что на Луне куча кратеров, и что он к этому отношения не имеет - не волнует).
А уязвимости в сервисах даже теоретически не дотягивают до уровней угроз, которые мы видим раз в полгода в нашем любимом модульном-монолите. Выходит, что для www2 чем опаснее уязвимость - тем лучше.
Но у меня иная система координат.> Xen - тоже микроядерный гипервизор. И что?
И всё. Рут в одном domU - не имеет отношения к руту в другом domU.
> Все domU и dom0, работающие под его управлением, автоматически становятся неуязвимыми?Подмена тезиса. Классика той же дьявольской логики.
Автоматически становятся защищёнными domX друг от друга.
Вобщем, вывод: микроядро вообще непричём, а жмёт именно вкомпиленная в мозг методичка стереотипной привычности.PS Чему плюсовали те трое?
вопрос изначально касался именно дырявости ядра, а не каких-то левых процессов и конкретной реализации.
марш за учебники
> Просмотрел первые 10 уязвимостей - это всё о юзер-левелеЕстественно в юзер-левле. Где ж ему ещё быть-то? Кернел-левел у микроядра (внезапно) микроскопический. :)
> Естественно в юзер-левле. Где ж ему ещё быть-то? Кернел-левел у микроядра (внезапно)
> микроскопический. :)У микроядра есть ещё сервисы.
Так вот ошибки не в микроядре, и не в сервисах, а в обычном юзерлевеле.
Или вы хотите сказать, что libкакая-то и всем-на-запись пермисии в rc.local - это ядерные проблемы?
> Или вы хотите сказать, что libкакая-то и всем-на-запись пермисии в rc.local - это ядерные проблемы?Я хочу сказать, что аргумент "это ж юзерлевел" в треде с обсуждением микроядерных ОС - звучит офигенно. :)
Терминология, друг, терминология. :)
> Я хочу сказать, что аргумент "это ж юзерлевел" в треде с обсуждением
> микроядерных ОС - звучит офигенно. :)
> Терминология, друг, терминология. :)Да, терминология (но Вы же меня поняли).
Да и сути не меняет: проблемы с пермиссиями и отдельными библиотеками - это не о качествах самой микроядерной модели.
> И существование GNU/Hurd - доказательство того, что это решение реально.Hurd существовал до Linux. Почему-то после того, как выпустили Linux, Hurd забросили. Решение то реально, только почему его не пилят вообще? Может быть есть причина всё же?
>> И существование GNU/Hurd - доказательство
> Hurd существовал до
> Решение то реально,
> есть причинаЗачем ставить таги https://ru.wikipedia.org/wiki/%D0%97%D0%... , говорили они. --"А раненных всё везут и везут."
> --"А раненных всё везут и везут."Оловянных, стеклянных или деревянных? :)
Пилить-то пилят, но в основном из интереса или в исследовательских целях. Причина в том, что когда Hurd начинали пилить, была задача заменить проприетарное ядро Unix в системе GNU.Разработчики Hurd-а начали пилить со взглядом в будущее, и хотели сделать всё сразу правильно. И это "правильно" упёрлось в непомерные сроки реализации, ибо ядро архитектурно было принципиально новым, с миллионами подводных камней и трудностями в отладке.
Тогда на сцене появился Linux. Взгляд у Торвальдса был проще: нужно новое ядро, и нужно ещё вчера. Linux в первую очередь ориентировался на то, чтобы был результат, и чтобы работали с ним уже существующие программы. И в этом Linux преуспел.
Тогда и выяснилось, что в среде разработчиков Hurd-а многим не нужно было "правильное" ядро, а они вполне довольствуются работающим. Тогда произошёл отток разработчиков, Hurd затормозился в развитии.
Так что сейчас сами разработчики GNU/Hurd пишут, что если бы Linux уже существовал, скорее всего они за Hurd бы не принялись.
> Разработчики Hurd-а начали пилить со взглядом в будущее, и хотели сделать всё сразу правильно.Пока семь раз отмеряли, Линус успел три раза сделать и переделать.
А вообще, интересно, как так получилось что один человек,
обогнал нескольких человек, которые ещё и начали делать раньше?
Подход "тяп-ляп - в продакшн" выстрелил?> Так что сейчас сами разработчики GNU/Hurd пишут, что если бы Linux уже существовал,
> скорее всего они за Hurd бы не принялись.Взялись за то, что им было не нужно?! 8-)
Или, просто не сообразили, что можно по-другому делать?
> Пока семь раз отмеряли, Линус успел три раза сделать и переделать.Типа того.
Монолит писать проще и логотип Пингвин тоже не последнее дело.> А вообще, интересно, как так получилось что один человек,
> обогнал нескольких человек, которые ещё и начали делать раньше?
> Подход "тяп-ляп - в продакшн" выстрелил?А что, коммерция. У кого быстрее - того и тапки (сливки).
И лишь через время (вот как счас) народ начинает соображать.
> А вообще, интересно, как так получилось что один человек,C небольшой помощью всяких айбиэмов и прочих, ага.
Айбиэмы подтянулись когда линукс уже был вполне работоспособен. В отличие от всяких хурдов.
Предлагаю назвать GNU KURD. Когда курды заполучат свое государство, тогда и допилят хурд.
>> Разработчики Hurd-а начали пилить со взглядом в будущее, и хотели сделать всё сразу правильно.
> Пока семь раз отмеряли, Линус успел три раза сделать и переделать.
> А вообще, интересно, как так получилось что один человек,Поищи рассылки за 1998-2004 гг, там с десяток основных разработчиков.
Без них бы эта поделка тихо бы покрывалась пылью в ftp архивах.
> Поищи рассылки за 1998-2004 гг, там с десяток основных разработчиков.
> Без них бы эта поделка тихо бы покрывалась пылью в ftp архивах.Слушайте, "успешный менеджер", а ведь у Вас проблемы то ли с историей, то ли с совестью.
К девяносто восьмому году, когда добрался до линукса -- его активно пилило далеко не десять человек, а пылью покрывалось что угодно, только не результат их труда.
Поищите, что ли, архивы lkml? Вот, скажем, этот день девятнадцать лет тому: https://lkml.org/lkml/1998/2/28
> Так что сейчас сами разработчики GNU/Hurd пишут, что если бы Linux уже
> существовал, скорее всего они за Hurd бы не принялись.Если мне не изменяет память, то Линус писал, что если бы не лицензионные проблемы у BSD, то он бы Linux не стал писать.
>> Так что сейчас сами разработчики GNU/Hurd пишут, что если бы Linux уже
>> существовал, скорее всего они за Hurd бы не принялись.
> Если мне не изменяет память, то Линус писал, что если бы не
> лицензионные проблемы у BSD, то он бы Linux не стал писать.Есть две версии
1 Линус с трудом понимал американские IT журналы
2 Он не осилил установку 386BSD
> Если мне не изменяет память, то Линус писал, что если бы не
> лицензионные проблемы у BSD, то он бы Linux не стал писать.Ещё версия: на его студне-щебродском 386SX не ставился FreeBSD (или какой-то из предков), требовавший тогда сопроцессора.
> Ещё версия: на его студне-щебродском 386SX не ставился FreeBSD (или какой-то из предков), требовавший тогда сопроцессора.386BSD вышла какбы на пол-года позже Linux.
>> Ещё версия: на его студне-щебродском 386SX не ставился FreeBSD (или какой-то из предков), требовавший тогда сопроцессора.Гм, Вирзениус пишет "+ i387"...
* Jan 5, 1991 bought his first PC (i386 + i387 + 4 MiB RAM and a small hard disk);--http://blog.liw.fi/posts/linux25/> 386BSD вышла какбы на пол-года позже Linux.
Да, наверное...
1991: Jan: 21yo Linus Torvalds buys 33MHz 386sx PC w/40Mb drive to play 'Prince of Persia' (hardware prices dropping dramatically), begins hacking Linux in April--compiled off of http://www.landley.net/history/mirror/robotwisdom/386.html + http://www.landley.net/history/mirror/robotwisdom/timeline.html
Jan 1991 to Jul 1992: Dr Dobbs publishes series by William Jolitz on porting BSD to 386
||1991: Feb? Berkeley includes Jolitz's free-but-incomplete 386 BSD on updated Networking Release 2
1991: 17Mar: William and Lynne Jolitz release version 0.0 of 386 port of BSD (386BSD released as free)
||no-date: Linus writes terminal emulator (or standalone newsreader?) for 386
1991: 25Aug: Linus solicits os-suggestions from comp.os.minix
1992: BSDI releases beta of BSD/386
...
.
....."" As far as I recall, 386BSD 0.0 was released about the same time as early Linux kernels. 386BSD was a complete system in the sense that it had all tools (which Linux didn't, originally), but the PC port was very flaky. For example, 386BSD 0.0 required a math coprocessor to work. FreeBSD and NetBSD appeared months later. "" --https://lists.gt.net/linux/kernel/16511#16511
Жуткая, стра-а-ашная археология. Not, панимашь, available и "даже нее смотрел" (интервью по ссылке с WP:).
"Linus Torvalds has said that if 386BSD or the GNU kernel had been available at the time, he probably would not have created Linux" --https://en.wikipedia.org/wiki/Berkeley_Software_Distribution...
> Если мне не изменяет память, то Линус писал, что если бы не
> лицензионные проблемы у BSD, то он бы Linux не стал писать.Немаловажно также отметить, что когда начинали писать Hurd, никакого BSD ещё не было.
> Если мне не изменяет памятьИзменяет.
Конечно. Монолит писать [было] проще, и железо было другим (пресловутые переключения контекста ааа!!!), сейчас же даже SYSENTER/SYSEXIT инструкции есть. А потом не стали писать, т.к. особо не пекло и поезд несколько отдалился (Линух оброс хорошей функциональностью).
>> И существование GNU/Hurd - доказательство того, что это решение реально.
> Hurd существовал до Linux. Почему-то после того, как выпустили Linux, Hurd забросили.
> Решение то реально, только почему его не пилят вообще? Может быть
> есть причина всё же?Основная причина - влияние классической модели безопасности UNIX на скорость работы микроядер.
Если тупо делать все требуемые проверки контроля доступа то в микроядрах получим жуткие тормоза.
Решение уже приведено в месте с доказательной мат моделью - отказ от классической модели тотальной проверки безопасности UNIX в пользу полной рандомизации: знает рандомный адрес имеет доступ, не знает - ядро немедленно убивает процесс, или даже все процессы пользователя с запретом их создания.
Вот хоть кто-то понимает в чем дело, а то все думают, что HURD недопили просто из-за лени...
Есть ещё гибридный подход: выносить в юзер-левел только нетребовательное к скорости (все яблочные огрызки так живут и DragonFly BSD). Тоже вполне подход.
А если не сложно, можно по подробней, есть ссылки на публикации с этой доказательной мат моделью?
https://sel4.systems/
> Плюсую.Если что, комментарий #2 свидетельствует только о полном непонимании проблемы (в лучшем случае -- о невнимательности и каше из архитектуры и патчей в голове).
> Микроядро - единственное РЕШЕНИЕ пролем надёжности Линукса.
> И существование GNU/Hurd - доказательство того, что это решение реально.Вы ведь правда с Hurd пишете, и туда точно шлют только мелко нарубленные патчсеты?
> Вы ведь правда с Hurd пишетеДык!
$ uname -a
Linux xxxxxxxx 4.4.0-64-lowlatency #85-Ubuntu SMP PREEMPT Mon Feb 20 12:39:25 UTC 2017 x86_64 x86_64 x86_64 GNU/LinuxЯ люблю Линукс. И хочу видеть в нём самое лучшее из доступного.
> и туда точно шлют только мелко нарубленные патчсеты?Не думаю, что мелконарубленный код без тестов способен грандиозно изменить ситуацию в лучшую сторону по качеству кода.
> существование GNU/Hurd - доказательство того,что жить и существовать не есть одно и то же.
>> существование GNU/Hurd - доказательство того,
> что жить и существовать не есть одно и то же.Жить и накатывать апдейты ядра. Всегда, каждый день.
И ребутиться. Ибо критические дырки.Вот это жизнь!
> Вот она -- монолитностьШагом марш в школу. Ядро уже давно не монолитное
Внезапно.
Прошу деталей.
>>> Вот она -- монолитность
>>Шагом марш в школу. Ядро уже давно не монолитное
> Внезапно.
> Прошу деталей.В монолитном ядре ты не можешь выгрузить какую-нибудь
подсистемы, обновить её и запустить снова по определению,
нужно перезапускать все ядро. Но вот
сюрприз благодаря модулям все это возможно в ядре Linux.
Глупости. Все эти подсистемы работают в одном адресном пространстве, и любая может порушить ядро самым жёстким образом. То что при этом их можно выгружать или подгружать -- к делу отношения имеет ровно столько же, сколько выгрузка страниц памяти в своп и подгрузка их обратно.
> Глупости. Все эти подсистемы работают в одном адресном пространстве, и любая может
> порушить ядро самым жёстким образом. То что при этом их можно
> выгружать или подгружать -- к делу отношения имеет ровно столько же,
> сколько выгрузка страниц памяти в своп и подгрузка их обратно.Вы путаете, я не утверждаю что ядро Linux микроядерное,
я говорю что ядро Linux не монолитное. Мир не черно белый.И про
>порушить ядро самым жёстким образом.теоретики такие теоретики, ну упала посистема для работы
с жесткими дисками в микроядре, при этом микроядро выжило,
ну и на хрена оно, ведь даже перезапустить подсистему не может,
т.к. жесткий диск не доступен.
> Вы путаете, я не утверждаю что ядро Linux микроядерное,
> я говорю что ядро Linux не монолитное. Мир не черно белый.Мир может и не чёрно-белый, тут ты прав. А вот ядра делят на монолитные и микроядерные, используя эти термины как антонимы. Монолитные держат в едином ядерном адресном пространстве очень много чего, микроядерные имеют много адресных пространств для многих подсистем. Если ты не веришь мне, то use google, luke. Переступи через своё презрение к теории и теоретикам, и почитай хотя бы определения тех понятий, который ты используешь.
> теоретики такие теоретики, ну упала посистема для работы
> с жесткими дисками в микроядре, при этом микроядро выжило,
> ну и на хрена оно, ведь даже перезапустить подсистему не может,
> т.к. жесткий диск не доступен.А если при этом система грузилась по сети? А если с сегфолтом упала не подсистема жёсткиих дисков, а графическая подсистема? Ты что-то тут говоришь о теоретиках, но сам при этом склонен к совершенно безумным обобщениям вида: если X не панацея, то X не нужно.
Упор на "единое адресное пространство" - в корне ошибочен. Грубо говоря - возможность практически все вынести из адресного пространства ядра это следствие микроядерности, а не определяющий признак.
Что ж, сильно подмечено.
Спасибо!
Ой мамо ... почитал бы ты Таненбаума ... может и лужи остались бы не расплёсканными :-\
>Мир может и не чёрно-белый, тут ты прав. А вот ядра делят на монолитные и микроядерные, используя эти термины как антонимы. Монолитные держат в едином ядерном адресном пространстве очень много чего, микроядерные имеют много адресных пространств для многих подсистемФайловые системы в user-space, char device драйверы в user space,
работа с SPI/I2C/Gpio/usb в userspace,
да те же проприетарные видео драйверы, если посмотреть их исходники (ядерная часть почти полностью открыта по крайней мере у NVIDIA), то можно понять что ядерная часть очень простая, и вся логика в userspace.
> ядерная часть почти полностью открыта по крайней мере у NVIDIAЧто за бред я прочитал? В драйверах нивидии открыта только интерфейсная прослойка между ядром и вставляемым в него блобом. При этом сам блоб, включая эту прослойку, весил раза в три больше самого ядра ещё 3 года назад, а сейчас наверняка распух ещё сильнее.
Или я отстал от жизни и это всё меняется? Не вставлял блоб себе в ядра уже эти самые 3 года.
>> ядерная часть почти полностью открыта по крайней мере у NVIDIA
> Что за бред я прочитал? В драйверах нивидии открыта только интерфейсная прослойкаНе знаю, что имел в виду человек, но вроде у нвидии началось движение в сторону DRM?
(тоже несколько лет как не наблюдаю на своих рабочих системах, впрочем)
>> Вы путаете, я не утверждаю что ядро Linux микроядерное,
>> я говорю что ядро Linux не монолитное. Мир не черно белый.
> Мир может и не чёрно-белый, тут ты прав. А вот ядра делят
> на монолитные и микроядерные, используя эти термины как антонимы.Есть ещё модульные и гибридные ядра. У Linux как минимум модульное ядро, а скорее даже гибридное, т.к. в Linux отдельные модули ядра выполняются как отдельные потоки ядра, что является признаком гибридного ядра. У DragonFly BSD и семейства Windows NT - гибридные ядра.
> Есть ещё модульные и гибридные ядра. У Linux как минимум модульное ядро,
> а скорее даже гибридное, т.к. в Linux отдельные модули ядра выполняются
> как отдельные потоки ядра, что является признаком гибридного ядра. У DragonFly
> BSD и семейства Windows NT - гибридные ядра.Да, жаль лишь, что от жонглирования названиями у кривых дров в Линухе уровень доступа не уменьшается...
> теоретики такие теоретики, ну упала посистема для работы
> с жесткими дисками в микроядре, при этом микроядро выжило,
> ну и на хрена оно, ведь даже перезапустить подсистему не может,
> т.к. жесткий диск не доступен.Нарушители логики - такие "логики".
Ну попытался подменить одним частным случаем все остальные возможные,
ну попробовал на этом построить свою теорию.
Но она осталась неприменима в общем случае.Да, в ядре куда больше драйверов, чем просто драйвер винта. И в случае проблем с ними - их безопасная и автоперезагрузка решает много проблем.
полностью согласен: микроядро не не решает проблему кривого кода в нужных подсистемах.
если нужный драйвер регулярно падает, то не нужно решать это проблему регулярным перезапуском. это как из лужи пить.
*я уж не говорю, что в системах с простыми dma и.т.д. защищенные области памяти могут быть запросто испорчены тем же самым криво работающим драйвером.нужно, чтобы все нормально работало. а если все нормально работает - то архитектура системы скорее дело вкуса.
> нужно, чтобы все нормально работало. а если все нормально работает - то
> архитектура системы скорее дело вкуса.Да, только почему-то по факту оно так не работает. Люди ошибаются, это их неотемлемое свойство, и пишут код с ошибками.
> пишут код с ошибками.Автоматический перезапуск падающего кода не очень-то способствует исправлению содержащихся в нём ошибок ("упало да и фиг с ним -- перезапустится и продолжит работать, а у нас других дел хватает"). Как-никак, лень людям тоже весьма свойственна.
> Автоматический перезапуск падающего кода не очень-то способствует исправлению содержащихся
> в нём ошибокНу так если перезапустилось и никто этого не заметил - то система хорошо делает своё дело.
А ошибки в коде - это больше к юнит-тестированию. Оно их хорошо профилактирует.
> ("упало да и фиг с ним -- перезапустится
> и продолжит работать, а у нас других дел хватает"). Как-никак, лень
> людям тоже весьма свойственна.Ну так серваки же для чего-то работают. И если оно таки делает своё дело - и хорошо. Проблем сейчас на Земле и без серваков хватает. Акамедически идеальное вылизывание кода - это уже слишком.
Чисто практичекая польза должна быть в приоритете.
Ну так если перезапустилось и никто этого не заметил - то система хорошо делает своё дело. - нет. просто истратило ресурсы на ровном месте. понятно, что это лучше чем упало, однако в драйверах чаще прочего имеет место неправильное поведение без порчи чего-либо.иначе говоря драйвер не упал, но перешел в состояние, в котором перестал правильно работать (или вообще работать).
> ну и на хрена оно, ведь даже перезапустить подсистему не может,т.к. жесткий диск не доступен.
А ничего, что подсистема уже загружена и находится в памяти?
Подсистема как бы упала и находится не пойми в каком состоянии.
В условии "задачи" упал тока драйвер винта, а не файловой системы (или кеша).
Так что, всё живёт, кроме доступа к "физике" винта.
>>порушить ядро самым жёстким образом.
> теоретики такие теоретики, ну упала посистема для работы
> с жесткими дисками в микроядре, при этом микроядро выжило,
> ну и на хрена оно, ведь даже перезапустить подсистему не может,
> т.к. жесткий диск не доступен.+1
И даже более того: упасть-то она упала, но выяснится это исключительно в рантайме. В этом потенциальная боль у возможности поменять любую часть системы на лету: многие ошибки, которые ранее могли бы быть пойманы на этапе компиляции, в итоге выявляются в рантайме.
>многие ошибки, которые ранее могли бы быть пойманы на этапе компиляции, в итоге выявляются в рантайме.А на монолите такого, конечно, быть не может совсем-совсем. "Когда вы говорите, такое ощущение, что вы бредите"(с).
> ведь даже перезапустить подсистему не может,
> т.к. жесткий диск не доступен.Вы слышали о кеше файловой системы?
Можете даже поиграться: грузонуть какой-нить liveCD, в консоли пускануть
/bin/ls, потом вынуть флешку и ещё раз запустить /bin/lsпосмотрите что получится
>> т.к. жесткий диск не доступен.
> Вы слышали о кеше файловой системы?Жёсткий диск недоступен - не в том смысле, о котором Вы подумали.
> Жёсткий диск недоступен - не в том смысле, о котором Вы подумали.Так жёсткий диск недоступен или ФС (бинарь для перезапуска драйвера)?
Это же разные сервисы (дрова).
На системах без IOMMU, любой драйвер может расписать под хохлому любую область памяти.
И никакое микроядро от этого не спасет.
> На системах без IOMMU, любой драйвер может расписать под хохлому любую область
> памяти.Ну Вы ж добавляйте,
это только, если ему позволить DMA...> И никакое микроядро от этого не спасет.
Зато спасёт от многих прочих проблем.
DMA без IOMMU - это проблема железной архитектуры. Странно обвинять в этом вложенный в неё софт.
Так можно договориться, что и возможность подойти к серваку и тупо его вырубить из розетки - это недобатотка какого-нить dBus'а
Напишите мне драйвер современного контроллера дисков или сетевой карты без dma.
И посмотрим на его производительность.
И?
Типа если оставить сервисам доступ к DMA (пока процы с IOMMU непомерно дороги), а всё остальное передать под контроль микроядра - то ситуация с надёжностью не улучшится?А пока всё это реализуется - там и IOMMU станет нормой в любом телефоне.
Доступ к DMA имеют не сервисы, а железки.
Потому, что сервисы (дрова) соотв. образом программируют эти самые железки.
Но это им возможно не позволить, ограничив определённые формы записи в порты (запись то в порты - под контролем микроядра).Потому, думаю, можно говорить и о доступе сервисов к DMA (опосредованно, через железку).
Стесняюсь спросить, слышал ли уважаемый эксперт по микроядрам про bus master dma.
> Стесняюсь спросить, слышал ли уважаемый эксперт по микроядрам про bus master dma.Ну раз каждый суслик - агроном (каждая железка может лезть в память), то и правильное решение - тоже аппаратное. Это MMU для контроля такого доступа (IOMMU).
Но даже без неё (пока оно дорогое и редкое), даже если все железки будут иметь доступ к памяти - то всё равно бОльшая часть проблем всё же идёт из кода дров ядра. А там - и IOMMU подтянется.
> В монолитном ядре ты не можешь выгрузить какую-нибудь
> подсистемы, обновить её и запустить снова по определению,
> нужно перезапускать все ядро. Но вот
> сюрприз благодаря модулям все это возможно в ядре Linux.Ну, вижу, Вас уже заминусовали нормально так.
Да, Вы спутали модульность и микроядерность.
Ты пытаешься тонко троллить или ты реально веришь в то, что написаное тобой, имеет отношение к проблеме описанной статьей?
Если второе, то у меня для тебя действительно плохие новости о твоем состоянии
>>"всё или ничего"
>Вот она -- монолитность. Жаль что GNU-тое ядро неактивно пилится.Бред, вы архитектуру (разделение программы на части и выделение API) и то как храняться исходники и как принимаются патчи.
Микроядерную ОС тоже могут хранить в одном репозитарии и с важными для ОС службами и возникла та же бы проблема.
ИМХО проблемы того, что подсистема не тестируется и работает абы как на честном слове, микроядро всё равно не решит.
И да, корректности ради, ядро всё-таки не классическое монолитное, а модульное.
Все - нет.
Проблемы защищённости всей системы от проблем в отдельных сервисах/дровах - Да.
А чтоб повысить качество кода - нужно тестировать, лучше автоматически.
И порог вхождения в эту возможность крепко опускает микроядро (т.к. тестить/девелопить в юзер-левеле куда проще).
> Все - нет.
> Проблемы защищённости всей системы от проблем в отдельных сервисах/дровах - Да.
> А чтоб повысить качество кода - нужно тестировать, лучше автоматически.
> И порог вхождения в эту возможность крепко опускает микроядро (т.к. тестить/девелопить
> в юзер-левеле куда проще).Переписывать монолитное ядро, с кучей дров, в которых кроме автора никто не разберется, тупо дорого. Да и некому. Да и куча костылей типа гиперхипстервизации есть.
Поэтому это как всегда и «НИНУЖНА и вабще, оно же медленное!»
Хотя основное суждение экспертов опеннетов о быстроте работы микроядер основано на кусках сра*ей из тех древнючих времен, когда суперкомпутеры в качестве числодробилок были на уровне современных смартфонов. А то, что у современных костылей для монолита тоже неплохой оверхед, вспоминать никто особо не любит.
> Переписывать монолитное ядро, с кучей дров, в которых кроме автора никто не
> разберется, тупо дорого.Тогда это READ/EXEC-ONLY код со всеми вытекающими: устранять ошибки в нём некому, что ведёт вникуда.
> Да и некому
Если глянуть статистику на том же гитхабе - то там каждый день тысячи и миллионы коммитов. Так что, разработчики есть. Но их идеи им интереснее. Если же заинтересовать их чем другим - то будет и кому.
> Поэтому это как всегда и «НИНУЖНА и вабще, оно же медленное!»
> Хотя основное суждение экспертов опеннетов о быстроте работы микроядер основано на кусках
> сра*ей из тех древнючих времен, когда суперкомпутеры в качестве числодробилок были
> на уровне современных смартфонов. А то, что у современных костылей для
> монолита тоже неплохой оверхед, вспоминать никто особо не любит.Да, всё так. Древние стереотипы и вообще вопрос не входит[л] в сферу интересов.
>Вот она -- монолитность. Жаль что GNU-тое ядро неактивно пилится.Ты не прав. При тех объемах, что имеется смена архитектуры не спасет. Хоть будь все на ООП. Хоть в микроядре. Без разницы. Тебе пришлют кусок школокода и сиди компиляй. Ах да, тесты тебе тоже никто не пришлет -- будешь сам писать. И т.д. и т.п.
Так что. Пили своё ядро. Расскажешь потом как ты один мониторишь 10 миллионов строк кода. И 1000+ людей, которые шлют тебе чуть ли не ежесекундо патчи. Будет интересно. А ты станешь знаменитым, богатым, забросишь опеннет и т.п. =)
Собсвтенно, как недавно столкнувшийся с ошибкой в финальной версии (начиная с 4.9), в частности, в подсистеме nouveau, могу сказать, что проблемы явно есть. Уже третью версию подряд (4.9, 4.10, 4.11) отправляют в ядро какие-то патчи-хаки, которые дублируют друг друга и решают проблемы тоже не полностью, периодически что-то откатывают, добалвюят новые хаки. Такое ощущение, что не тестировали вообще. В итоге в ядре есть баги со статусом "critical highest blocker". Конечно, слепо обновляться на новую версию нельзя, но иногда новые версии могут решать существенные проблемы, да и кто-то должен их тестировать. Я бы понял, если бы был какой-то план по внедрению патчей, что к LTS релизу таких проблем не будет, но в итоге именно в LTS релизе, несмотря на хак, проблема все равно останется и навсегда.Все вышесказанное относится только к DRM.
А прошлонедельная CVE-2017-6074 не относится к качеству кода ядра?
Может быть и относится, откуда я знаю? Я ведь столкнулся с конкретной подсистемой, и в контексте новости описал ситуацию, которую увидел собственными глазами. А вы спрашиваете про что-то иное.
> Может быть и относится, откуда я знаю? Я ведь столкнулся с конкретной
> подсистемой, и в контексте новости описал ситуацию, которую увидел собственными глазами.
> А вы спрашиваете про что-то иное.Понял.
Вобщем, относится и это
вообще-то когда у кого-то что-то не компилируется, в интернетах принято делать крайним компилирователя, а не код. ещё принято использовать аргумент "у Меня всё работает"так вот, это у линуса просто руки кривые! :)
> вообще-то когда у кого-то что-то не компилируется, в интернетах принято
> так вот, это у линуса просто руки кривые! :)Его рычаг больше -- он же мержит.
Что ещё не понятно, спрашивай?
//
И вообще, на форониксах уже успели _две_ новости сделать "ой, Он ругается" + "уф, обошлось". В сумме дающие эталонный "Пшшшшик!" -- эту (одну) новость здесь. Впрочем, то, что у хороводов корпорастов опять проблемы с разработкой можно, и пообсуждать "новую модель", апгрейды гита и проч. -- бурление ж.
Что меня злит, так это то что плохой проприетарный драйвер можно накатить на систему двух, трёх и пятилетней давности, и всё будет работать. А хороший открытый драйвер начинает корёжить от разницы в 2 месяца между релизами любых из двух компонентов: Linux, libdrm, xf86-video-driver и Mesa. Интел хоть предупреждение показывает в командной строке: "gen6+ needs Linux 4.1", что-то такое. У остальных всё просто не компиляется или не работает.
> Что меня злит, так это то что плохой проприетарный драйвер можно накатить
> на систему двух, трёх и пятилетней давности, и всё будет работать.Но наоборот часто как раз не работает, а чаще и не компилируется.
Попробуйте скажем драйвер проприетарный nvidia для свежего ядра собрать,
в большинстве случаев ошибки компиляции.
Сейчас прекрасно собирается... у них был момент, когда пару месяцев были проблемы, но в остальном закрытые дрова nvidia собираются на всем новом гораздо раньше, чем amd например.
Так какой из них по факту хороший, а какой плохой?
А на свежую можно?
> У остальных всё просто не компиляется или не работает.Stable API nonsense, едрить его за ногу. Заморозка API/ABI на веки вечные, конечно, создаёт проблемы, но и регулярные изменения в расчёте на "исходники открыты -- кому надо, поправят", IMHO, тоже не дело.
Кто-то ещё сомневается, что Линуксу давно пора менять дизайн на микроядро?Это ж оно в сабже просто не скомпилилось у Торвальдса. А если бы скомпилилось? Но никакого тестирования то там всё так же и не было...
Да и сейчас, в монолитном виде тестировать отдельные модули ядра, кроме как собрать ВСЁ, загрузить и погонять - некак. (а хоть какие-то тесты есть только в btrfs модуле)
Остаётся не у дел самый эффективный подход - разработка через тестирование. Причём, в самой критичной части операционки...
Микроядерный же подход позволяет имитировать микроядро для модуля, и делая контрольные вызовы - контроллировать что модуль зовёт дальше: есть ли нужные обращения к железу (через выховы микроядра) и прочим сервисам.
Ну и излишне говорить о безопасности, даже если какая ошибка вкрадётся в какой сервис - это всё-таки, уже отдельный процесс. Даже если навернётся - то будет просто перезапущен. Всё остальное продолжит работу.
У микроядерной модели есть свои проблемы и стереотипы в отношении них.
Но всё решаемо.Есть вот, к примеру, Debian GNU/Hurd - вполне живая система с 50к пакетами, живёт sshd и накатываются апдейты по сети (из qemu).
PS Минусующим просьба: пишите словами против чего именно Вы против.
Микроядерных полон тред. Вы тут чего забыли?
Мы тоже любим Линукс за его функциональность.
Но не хотим, чтобы он канул в лету под грузом принципиально нерешаельных проблем ненадёжной структуры.А что Вы предлагаете? Как решать эти вот проблемы в сабже и прошлонедельные рутовые уязвимости из-за опечатки (?) в левом модуле?
> Но не хотим, чтобы он канул в лету под грузом принципиально нерешаельных проблем ненадёжной структуры.Это естественный процесс. Нельзя просто так писать/писать/писать на протяжении этак 30 лет.
Постепенно любой проект придет к состоянию "надо взять и переписать". Сейчас всякие расты встают. Поэтому ждем Rinix этак через пять лет.
PS: возьмите и запишите это предсказание на бумажку, а если не сбудется, то выкиньте.
Слабая мотивация. Хранить чтобы потом, если чего, выбросить ))
> Постепенно любой проект придет к состоянию "надо взять и переписать". Сейчас всякие
> расты встают. Поэтому ждем Rinix этак через пять лет.
> PS: возьмите и запишите это предсказание на бумажку, а если не сбудется,
> то выкиньте.Ну не Rinix оно называется, а чуть иначе. Но уже есть, и снова же - микроядро.
Старые песни на новый лад. А вот был бы у Линуса короткоствол, а вот было бы ядро микроядерным...
> Старые песни на новый лад. а вот было бы ядро микроядерным...А Вы как решаете насущные проблемы?
Просто что-то меняете, а потом расхлёбываете?
Или вначале подумать и обсудить с другими заинтересованными?Так что да, вопрос более чем справедлив: да, микроядро может решить обозначенные проблемы надёжности. А какие есть сопутствующие нюансы?
Потерю 1-2% производительности на пресловутых доп. переключениях контекста можно не особо педалировать; это мелочи в сравнении с вопросами именно передачи данных между сервисами.
Существует мнение, что это нужно делать строго асинхронно (что порождает очереди запросов, а в больших NUMA системах с тысячами процов добавляет внушительные затраты на поиск наилучшего места в памяти для каждого сообщения), но даже по структуре монолита видно, что на каждом процессоре запускается свой отдельный поток уже многих внутриядерных подсистем. Почему бы так же не делать в микроядре? - потребности в очередях и не будет: сервисы будут просто вызывать соотв. нитку на своём процессоре, не мешая работать другим.
Простите, но вы хотя бы, в теории, знаете во что вываливается переключение контекста? Наверное, из рук не выпускаете книги Эндрю Таненбаум и знаете как внутри все это работает, верно?
В точку.
Ещё ответьте за всех, что добавить 5 копеек в запас мощности железа это всегда хуже, чем устраивать даунтайм из-за левых ошибок.
Переключения контекста это не разу не пять копеек. Для иллюстрации можете посмотреть на производительность и прожорливость процессора ntfs-3g.
Не уверен, что данная реализация сервисов (fuse) - оптимальна.
Кроме того, это частный случай, а не сами по себе переключения.Но что-то да, в этом примере посмотреть можно. И увидеть как и тормоза, так и бОльшую надёжность. И вот тут как раз и начинается разница приоритетов: кому и что нужно.
Может кто готов добавить те самые 5 копеек и закрыть вопрос проседания производительности, не теряя надёжности из-за необходимости работать со специфическим драйвером.
Ну а кому важна скорость и не проблема ребутнуться - дык у них уже и так всё есть.
Вопрос наличия выбора.
Началось виляние филейной частью, покажите более оптимальную.
Почему-то никто за более чем 30 лет ниасилил.
> Началось виляние филейной частью, покажите более оптимальную.Вот об этом и речь. Но в более общем виде.
>> Почему-то никто за более чем 30 лет ниасилил.На этот ваш постоянный вопрос всегда есть постоянный ответ - QNX. Отличная операционка. Единственные ее недостатки - только рилтайм, а не универсальность назначения (со свопом) и отсутствие полной открытости и свободы для сообщества, лицензия
> Единственные ее недостаткиЕдинственный недостатки -- уже ободряет; может, попробуем развернуть на нескольких тысячах узлов вычислительного кластера или вот на wifi-маршрутизаторе?
PS: помню ту дискетку, ага. Симпатичная была штука.
>> может, попробуем развернуть на нескольких тысячах узлов вычислительного кластератеоретически архитектура ее как нельзя лучше для этого подходила - ее IPC базируется на отправке сообщений (синхронных и асинхронных), причем даже прозрачно через сеть. При нужде даже какой-нибудь драйвер может работать на другом узле (он ведь тоже всего лишь юзерспейс-программа, обрабатывающая поступающие сообщения)
>> или вот на wifi-маршрутизаторе?
Ну для сетевых нужд модифицированные варианты QNX циска где-то использовала (-зует?). Из википедии:
"Cisco Systems использует оптимизированную версию микроядра QNX Neutrino в программном обеспечении IOS XR[17]. Программный пакет IOS XR предназначен для управления коммутаторами Cisco CRS-1, обеспечивает непрерывный режим работы и поддерживает развитые функции управления терабитными коммутаторами с распределённой архитектурой."Т.е. при желании наверное можно и правильные wifi-драйвера написать (производителю железа), а маршрутизация, думаю, в стеке TCP/IP QNX-а наверное присутствует
Повторюсь, для меня там недостаток - проприетарность. И второе - это не ОС универсального назначения (еще раз повторюсь - как частное следствие - нет того же свопа)
Если бы его вовремя сделали паблик домейн/GPL - думаю его бы доточили до ОС универсального назначения, а дальше и до полноценной работы на тысячах узлах вычислительных кластеров и для работы в вифи-маршрутизаторах. Но история не терпит сослагательного наклонения
>> PS: помню ту дискетку, ага. Симпатичная была штука.
да, только я помню небольшую стопку дискеток (какая-то из версий QNX4), там еще графическая система была. Помню, меня порвало, когда я на 80386 (с сопроцессором) получил ОС с настоящей вытесняющей многозадачностью, а не Windows 3.x с кооперативной. Но вот с прикладным софтом, конечно, была другая ситуация, ну на то она и специализированная ОС жесткого реального времени (хотя несколько позже было забавно на QNX6 запускать квейк2)
>>> может, попробуем развернуть на нескольких тысячах узлов вычислительного кластера
> теоретически архитектура ее как нельзя лучше для этого подходила - ее IPC
> базируется на отправке сообщений (синхронных и асинхронных), причем даже прозрачно через
> сеть.Справедливости ради: стереотип обязательной асинхронности доставки IPC сообщений - реально порождает громадный (неприемлемый) оверхед на тысячах процов. А разбивка обычного многопоточного софта на запускаемость впараллель на разных хостах (к отправке IPC по сети) - это отдельная работа.
https://www.kernel.org/doc/ols/2007/ols2007v1-pages-251-262.pdf
Поэтому, оставаясь в плену стереотипа обязательной асинхронности IPC в микроядре - разработчики монолита демонстрируют чудеса на многотысячепроцовых системах.
> Справедливости ради: стереотип обязательной асинхронности доставки IPC сообщенийтам же было написано "...ее IPC базируется на отправке сообщений (синхронных и асинхронных)..." ----> "(СИНХРОННЫХ и асинхронных)..."
в QNX отправка сообщения может быть и синхронной, от разработчика программы зависит
> там же было написано "...ее IPC базируется на отправке сообщений (синхронных и
> асинхронных)..." ----> "(СИНХРОННЫХ и асинхронных)..."Да, в QNX есть и то, и другое, и это правильно.
Но проблема масштабируемости всё так же под вопросом (нужны публикации на эту тему), причём, переработка пользовательского софта под сетевые параллельные вычисления - не вариант.
а разработчики монолита демонстрируют чудеса производительности перед микроядерщиками из-за значительно меньшего количества переключений контекста задач. Так что жизнь - сплошные компромиссы
> а разработчики монолита демонстрируют чудеса производительности перед микроядерщиками
> из-за значительно меньшего количества переключений контекста задач. Так что жизнь -
> сплошные компромиссыКак будто производительность - всегда важнее всего...
> Повторюсь, для меня там недостаток - проприетарность. И второе - это не
> ОС универсального назначения (еще раз повторюсь - как частное следствие -
> нет того же свопа)
> Если бы его вовремя сделали паблик домейн/GPL - думаю его бы доточили
> до ОС универсального назначения, а дальше и до полноценной работы на
> тысячах узлах вычислительных кластеров и для работы в вифи-маршрутизаторах. Но история
> не терпит сослагательного наклоненияДа терпит история. Моделировать прошлое и будущее - очень даже нужно и полезно (чтоб не наступать снова).
А по поводу проприетарности - похоже, есть какая странная закономерность: проприетарщики вовсю пользуют микроядро для достижения высокой надёжности (те же американские вояки и огрызочники), а в массэ вбрасывается нежизнеспособность такой модели. Кому-то хочется монопольно качественной работы своих систем?
наверное потому, что никто больше столько человеко-дней в это больше и не вливал
развивали то, что посчитали более удобным и приоритетным
остальное существует ровно потому, что есть задачи нерешаемые данным инструментом с приемлемым качеством
очевиднейшие же вещи, но нет, у нас одни лозунги в голове... сектанты, етить
> Микроядерных полон тред. Вы тут чего забыли?Они недавно микроядерность проходили )
>> Микроядерных полон тред. Вы тут чего забыли?
> Они недавно микроядерность проходили )Не, талмуд Таненбаума оставляет неизгладимую травму _надолго_. Не "недавно", то есть. ><:>
Я против странно коррелирующих наплывов фанатов микроядерности и микрософта.
Лови минус.
Спасибо за конкретику по минусу.Хотя странно: за наплавы статистики посещаемости ресурса лично я не отвечаю, но минус прилетает именно мне... Ну что ж...
Да, если по микроядру есть мысли - прошу.
Куратор твой отвечает.
По микроядру задачка тебе такая на размышление: оцени, сколько сил на это уйдет, и насколько велик возможный выигрыш. А то указывать, куда идти линуксу, ты, конечно, горазд.Ну и да, пассажи вроде
>Да и сейчас, в монолитном виде тестировать отдельные модули ядра, кроме как собрать ВСЁ, загрузить и погонять - некак.Выдают глубину твоих познаний в предметной области с головой.
> По микроядру задачка тебе такая на размышление: оцени, сколько сил на это
> уйдет, и насколько велик возможный выигрыш.Возможный выигрыш: в мире продолжит жить и развиваться самое функциональное открытое ядро общего назначения, а не загнётся под весом своих проблем, вынуждая народ разбегаться по всяким *BSD или - не дай Бог - оффтопикам.
Думаю, этот выигрыш достоин любого объёма человекочасов.
> А то указывать, куда идти линуксу, ты, конечно, горазд.Спасибо.
Вы тоже можете попробовать предложить путь развития. Это никому не запрещается.
> Ну и да, пассажи вроде
>>Да и сейчас, в монолитном виде тестировать отдельные модули ядра, кроме как собрать ВСЁ, загрузить и погонять - некак.
> Выдают глубину твоих познаний в предметной области с головой.А я на экзамене? Или речь обо мне?
Я думал, что речь о Линуксе.Есть конечно отдельные автоматические тесты по некоторым подсистемам (find|grep test), но их объём несопоставим с объёмом всего кода (т.е. покрытие - мизерное).
Потому, тестируют всё ядро целиком сборками случайных конфигов (да, это и значило "собрать ВСЁ, загрузить и погонять"), а отдельные дрова в процесса разрабоки - в лучшем случае перезагрузкой модуля. Невыгружаемые же части ядра тестятся перекомпиляцией и бутов в это ядро.
Вы ещё какие-то споособы тестирования текущего Линуха знаете?
>Возможный выигрыш: в мире... (наступит, короче, коммунизм)Ты давай вот эти прокламации оставь для кого-нибудь другого. Линукс не самоцель. Возьми и посчитай. С обоснованиями.
>Вы тоже можете попробовать предложить путь развития. Это никому не запрещается.
Еще раз говорю, более понятно: звездеть на форуме - не мешки ворочать. Иди и делай. Будешь указывать, куда идти другим - другие однажды скажут, куда идти тебе.
>А я на экзамене? Или речь обо мне?
О тебе, студент, о тебе. Ты берешься рассуждать о тех вещах, о которых имеешь весьма смутное представление.
>Есть конечно отдельные автоматические тесты... (опять много воды)
Тестирование и архитектура ядра - вещи ортогональные. Это вопрос организационный, а не вопрос микроядерности.
> Ты давай вот эти прокламации оставь для кого-нибудь другого. Линукс не самоцель.
> Возьми и посчитай. С обоснованиями.Зачем?
Это что, коммерческий проект или где?
Или кому-то станет легче, если появится циферь, что для этого нужно N+1 человекочасов?
Это добавит сторонников микроядерного подхода? - не думаю.> Еще раз говорю, более понятно: звездеть на форуме - не мешки ворочать.
> Иди и делай.Я и делаю.
Меж прочим, пересматривать устоявшиеся стереотипы (а тем паче помогать в этом другим) - очень сложная и неблагодарная (но необходимая) работа.> Будешь указывать, куда идти другим - другие однажды скажут, куда идти тебе.
Вы меня с кем-то путаете.
Кому я и где указал?
Какому субъекту я вот прям взял и что-то начал рассказывать что делать?
Не было этого. Даже Торвальдсу я ничего не указывал.
Перечитайте, если не верите.
> О тебе, студент, о тебе. Ты берешься рассуждать о тех вещах, о
> которых имеешь весьма смутное представление.Заметьте, сколько всего Вы уже написали, но о микроядре пока ни слова (всё какие-то нравоучения что я не так что-то [не]делаю). Я же о нём написал хоть что-то. По одному этому параметру можно судить о наших представлениях.
> Тестирование и архитектура ядра - вещи ортогональные. Это вопрос организационный, а не
> вопрос микроядерности.Согласен. Другого и не утверждал.
Просто микроядро переводит разработку дров в юзерзлевел, что проще (прослойка API уже готова, раз и для всех, не нужно тратить время для написания заглушек).
>Это что, коммерческий проект или где?Это тут ни при чем. Посчитать прошу не в деньгах, а в часах.
>Или кому-то станет легче, если появится циферь, что для этого нужно N+1 человекочасов?
Тебе должно полегчать, когда осознаешь, что это титанический труд, не стоящий свеч.
>Это добавит сторонников микроядерного подхода? - не думаю.
Правильно, не добавит, см. выше, почему.
>Я и делаю.
Результаты где? Сколько сил потрачено уже и каких успехов достиг проект?
>Меж прочим, пересматривать устоявшиеся стереотипы (а тем паче помогать в этом другим) - очень сложная и неблагодарная (но необходимая) работа.
Угу. Похоже, предыдущий вопрос снимается.
>Заметьте, сколько всего Вы уже написали, но о микроядре пока ни слова
Потому что нет предмета спора. Забавно, но ты не написал про микроядро тоже ничего, ты лишь безосновательно пытаешься утверждать, будто бы архитектура ядра разом решит все организационные вопросы и какие-то сферические "надежности" и "безопасности" в вакууме и *спасет линукс* (конечно же, без ссылок на авторитетные исследования и подсчеты). И вот, например, опять:
>Просто микроядро переводит разработку дров в юзерзлевел, что проще
Это бессодержательное утверждение, понимаешь? С ним невозможно поспорить. Что проще? Кому проще?
И так у тебя все.
> Это тут ни при чем. Посчитать прошу не в деньгах, а в часах.Ничего это не поменяет, и проблем в Линухе не убавит.
>>Или кому-то станет легче, если появится циферь, что для этого нужно N+1 человекочасов?
> Тебе должно полегчать, когда осознаешь, что это титанический труд, не стоящий свеч.При чём тут я?
Ну титанический, и что? Это ж всё уже раз написали люди. Значит и переделать смогут, когда осознают необходимость.
Временем то не связаны.
Главное - знать правильный путь.>>Я и делаю.
> Результаты где? Сколько сил потрачено уже и каких успехов достиг проект?Куча народу на опеннете задумалось (кто в какой степени, конечно) о проблемах Линукса, о путях их решения, и, в частности, о пути микроядра.
Некоторые из этого числа ещё какое-то время будут думать над этим, кто-то ещё что-то придумает, а кто-то изменит своё мнение. И всё это - в плюс к _долгосрочному_ решению проблем Линуха.
>>Заметьте, сколько всего Вы уже написали, но о микроядре пока ни слова
> Потому что нет предмета спора.Да, есть вопрос, а не спор: как окончательно решить все эти проблемы устойчивости и качества кода Линукса?
> Забавно, но ты не написал про микроядро тоже ничего
Странно, в моей Вселенной я в этой ветке напостил кучу постов о микроядре.
> ты лишь безосновательно пытаешься утверждать, будто бы архитектура ядра
> разом решит все организационные вопросыВы снова меня с кем-то путаете... ну бывает.
> и какие-то сферические "надежности" и "безопасности" в вакууме и *спасет линукс*Почему сферические?
Разве не добавляет системе надёжности то, что браузер (драйвер веба меж прочим ;) работает в отдельном адр. пространстве, а не в ядре?
Почему тогда такой же подход к остальным дровам не улучшит ситуацию?
> (конечно же, без ссылок на авторитетные исследования и подсчеты).а.... Вам авторитетов подавай... своей головой не можете подумать...
Ну, что ж. Таковых счас большинство (увы).
>>Просто микроядро переводит разработку дров в юзерзлевел, что проще
> Это бессодержательное утверждение, понимаешь? С ним невозможно поспорить. Что проще? Кому
> проще?
> И так у тебя все.Проще, потому, что есть заданный API, через который нужно общаться с железом и прочими сервисами, и - главное - через это API возможна разработка через тестирование (TDD), что позволяет тестить написанное и в юзер-левеле, причём во всех режимах работы самого железа. Это подразумевает запись в форме тестов того, как должна работать железка.
Даже если разработка драйвера идёт путём прощупывания железки, не имея документации производителя. Просто все "раскопки" записываются в форме тестов - и будут проверять на соответсивие уже сам код.
>Ничего это не поменяет, и проблем в Линухе не убавит.Да неужели? А вот твои дифирамбы микроядру, конечно, все поменяют и все проблемы решат!
>Ну титанический, и что? Это ж всё уже раз написали люди. Значит и переделать смогут, когда осознают необходимость.
Теперь докрути свою мысль до конца, не бойся: необходимости в этом нет, вот и никто не переписывает.
>Главное - знать правильный путь.
Очередное бессодержательное утверждение за все хорошее. А кто сказал, что микроядро - правильный путь?
>Результаты где?
>>Куча народу на опеннете задумалосьМолодец какой, очень результативен твой проект микроядерного линукса, ничего не скажешь!
>Да, есть вопрос, а не спор: как окончательно решить все эти проблемы устойчивости и качества кода Линукса?
Никак, и дело не в архитектуре и вообще не в линуксе. Был бы знаком с предметной областью (программная инженерия) - не задавал бы таких глупых вопросов.
>Странно, в моей Вселенной я в этой ветке напостил кучу постов о микроядре.
Кучу напостил, вот именно. Толку ноль, смысла ноль.
>Вы снова меня с кем-то путаете... ну бывает.
Не путаю, нет.
>Почему сферические?
Без конкретики потому что.
>Разве не добавляет системе надёжности то, что браузер (драйвер веба меж прочим ;) работает в отдельном адр. пространстве, а не в ядре?
Браузер и сейчас не работает в пространстве ядра. Ты совсем плаваешь, дружок!
>а.... Вам авторитетов подавай... своей головой не можете подумать...
Ньютон говорил, что стал великим, потому что стоял на плечах гигантов. Но кукаретик-микроядерщик, несомненно, умнее всех ученых-современников.
Что ж, можно и своей, почему бы и нет? Покажи хотя бы одну свою публикацию на тему, очень интересно будет обсудить.>Это подразумевает запись в форме тестов того, как должна работать железка.
Молодец какой! А ничего, что эта сферическая в вакууме программная модель железки, потребует усилий на написание гораздо больше, чем написание драйвера для нее же? Но это полбеды - главная беда в том, что тестирование на такой ущербной модели все равно ничем тебе не поможет.
Вишенка на торте - такой тест можно и монолитному ядрому состряпать с таким же успехом, никаких преимуществ микроядерности тут нет.
> Очередное бессодержательное утверждение за все хорошее. А кто сказал, что микроядро -
> правильный путь?А как иначе оградить доступ тому, чему не нужно всё, а достаточно лишь своей памяти?
> Молодец какой, очень результативен твой проект микроядерного линукса, ничего не скажешь!Вообще-то, любой немалый проект начинается с обсуждения. Нет?
(кто-то ниже об инженерии говорил?)
>>Да, есть вопрос, а не спор: как окончательно решить все эти проблемы устойчивости и качества кода Линукса?
> НикакПонял. Тогда к Вам вопросов больше нет.
> и дело не в архитектуре и вообще не в линуксе. Был
> бы знаком с предметной областью (программная инженерия) - не задавал бы
> таких глупых вопросов.Мой вопрос отличается ещё и предложенным вариантом ответа на него.
>>Разве не добавляет системе надёжности то, что браузер (драйвер веба меж прочим ;) работает в отдельном адр. пространстве, а не в ядре?
> Браузер и сейчас не работает в пространстве ядра. Ты совсем плаваешь, дружок!Что-то Вы в своей истерике не понимаете написанного. Перечитайте ещё раз. Я не утверждал, что он в ядре работает.
> Что ж, можно и своей, почему бы и нет? Покажи хотя бы
> одну свою публикацию на тему, очень интересно будет обсудить.Неплохая точка старта:
microkernel _точка_ info
> Молодец какой! А ничего, что эта сферическая в вакууме программная модель железки,
> потребует усилий на написание гораздо больше, чем написание драйвера для нее же?Удивительно, но чтобы что-то сделать - нужно делать.
Сам драйвер не говорит ничего о простом вопросе: а так ли он работает, как задумывалось? Просто потому, что то, как задумывалось - написано разве что в Documentation/* на человеческом языке, и проверять - следовательно - нужно тратить время именно человеку. Но все вокруг продолжают страдать, что нет времени.
> Но это полбеды - главная беда в том, что тестирование
> на такой ущербной модели все равно ничем тебе не поможет.Если есть тесты и нет тестов - не дают никакой разницы, то вопрос о программной инженерии лучше закрыть.
Извините, если побеспокоил.
> find|grep testНадеюсь, это была не цитата?
>> find|grep test
> Надеюсь, это была не цитата?Возможно, но ссылку счас уже не найду. Где-то затерялась в закладках...
>>> find|grep test
>> Надеюсь, это была не цитата?
> Возможно, но ссылку счас уже не найду. Где-то затерялась в закладках...А без закладки можете сказать, что именно должна вернуть такая команда?
> А без закладки можете сказать, что именно должна вернуть такая команда?Предполагался запуск в дереве сырцов 4.4 Линуха.
В целях ознакомиться с общим состоянием тестирования кода ядра.
>>>>> find|grep test
>> А без закладки можете сказать, что именно должна вернуть такая команда?
> Предполагался запуск в дереве сырцов 4.4 Линуха.Не цель, а что вернёт. Вы же ратуете за тесты? Пока этот сами не прошли.
> Не цель, а что вернёт. Вы же ратуете за тесты?Много чего вернёт. (смысл приводить общеизвестную "простыню"?)
Будет видно, что что тесты есть, но избирательные, покрыт далеко не весь код.
>> Не цель, а что вернёт. Вы же ратуете за тесты?
> Много чего вернёт. (смысл приводить общеизвестную "простыню"?)
> Будет видно, что что тесты есть, но избирательные, покрыт далеко не весь
> код.
% find /usr/src -type f -ipath "*test*" | wc -l
10259
% find /usr/src -type f | wc -l
72617% find /usr/src/ -path "*.git*" -prune -o -ipath "*test*" -type f -print | wc -l
10259
% find /usr/src/ -path "*.git*" -prune -o -type f -print | wc -l
70317% find /usr/src/ -path "*.git*" -prune -o -ipath "*test*" -type f -print0 | gdu -ch --files0-from=-|tail -n1
90M total% find /usr/src/ -path "*.git*" -prune -o -type f -print0 | du -ch --files0-from=-|tail -n1
1,2G total
Оно?
Да, примерно.
Я лишь был о ядре Линухе.
А зачем вызов grep'а?
Микроядро лишает Линуса власти и требует от него сохранять неизменным API. Сейчас оный разделился на несколько частей:
- собственно API
- GPL_ONLY функции, которые можно вызвать только будучи слинкованным с ядром
- функции, которые можно вызвать в ядре, не входящие в APIСостав последних двух меняется по желанию левой пятки.
Параметры (перечень, порядок, значения констант) всех упомянутых меняются непредсказуемым образом.
Сейчас это вылазит на этапе компиляции и в случае серьёзных изменений приводит к невозможности компиляции (как в упомянутом случае, когда тестировали на старой версии ядра, а у Линуса новое).
Можно отказаться от много, но не от власти.
Если что, тылы у Торвальдса закрыты. Он уже лет 10 сам предлагает перейти на микроядро.
Вот напр. очередные изливания на эту тему образца 2009 г.:
> Микроядро лишает Линуса власти и требует от него сохранять неизменным API.Дык почему же? Межсервисное API можно менять хоть по 10 раз на дню. Микроядерность этому никак не мешает.
> Сейчас это вылазит на этапе компиляции и в случае серьёзных изменений приводит
> к невозможности компиляцииКомпиляция - это ладно. Но автоматизированных тестов то функциональности нет...
> Можно отказаться от много, но не от власти.Ну а власть - в конечном счёте её всегда БЕРУТ, а не дают. И пока нет претендента, Торвальдс - своего рода монополист. Невзирая на модель ядра.
> Если что, тылы у Торвальдса закрыты. Он уже лет 10 сам предлагает
> перейти на микроядро.Если бы предлагал - то мы бы уже давно имели ли бы Микроядерный Линукс (как минимум, отдельную ветку).
А так, почитал я ту новость - он сам лично не произносит слова "микроядро", но да, в обсуждениях есть предложения, что "пора".
> он сам лично не произносит слова "микроядро"Конечно нет! Сказал "а", говори и "б". Нужно намёками вынудить других это делать, чтобы в случае успеха приписать его себе, а в случае неудачи свалить его на них. Обрати внимание вот на этот "тонкий намёк":
https://www.opennet.me/opennews/art.shtml?num=32838
Он считает ситуацию недопустимой и хвалит сам себя за то, что организовал её именно так.
> своего рода монополист
Уверен? Когда МС было нужно, они пропихнули любой объём кода, который посчитали нужным. Сейчас это нужно ряду компаний и они пропихивают DRM. Торвальдс кроет их матом, но принимает их патчи в приоритетном порядке, не взирая на явные косяки.
Микроядерность сделает драйвера независимыми от ядра. Это приведёт к тому, что появится ещё один слой API (т.н. "Kernel API") - стандартизированную (!) версию функций, перечисленных выше.
> Конечно нет! Сказал "а", говори и "б". Нужно намёками вынудить других это
> делать, чтобы в случае успеха приписать его себе, а в случае
> неудачи свалить его на них.Что ж, такая себе "перестраховка".
Впрочем, в текущем обществе лидеры просто обязаны высказываться неоднозначно. Т.к. интересы элитариев и их корпораций конкретно противостоят интересам трудового большинства.
> Обрати внимание вот на этот "тонкий намёк":
> Он считает ситуацию недопустимой и хвалит сам себя за то, что организовал
> её именно так.Ну хвалит - и молодец.
Вообще, поклон ему в ноги за то, что он УЖЕ сделал в своей жизни.
Ну а дальше - не только он умеет vim'ить код.
>> своего рода монополист
> Уверен? Когда МС было нужно, они пропихнули любой объём кода, который посчитали
> нужным. Сейчас это нужно ряду компаний и они пропихивают DRM. Торвальдс
> кроет их матом, но принимает их патчи в приоритетном порядке, не
> взирая на явные косяки.Ну раз только ему делают такие широкие предложения, "от которых невозможно отказаться", значит монополист ;)
Но завершение монополии достигается появлением альтернативы...> Микроядерность сделает драйвера независимыми от ядра. Это приведёт к тому, что появится
> ещё один слой API (т.н. "Kernel API") - стандартизированную (!) версию
> функций, перечисленных выше.Да, безусловно.
И это будет славно. Стандартизация - упрощает жизнь многим.
> Остаётся не у дел самый эффективный подход - разработка через тестирование.есть доказательства, что этот подход - самый эффективный из существующих? Сколько не видел попыток внедрения данного подхода - ни разу не было отмечено позитивных изменений, даже если разработка ведется вообще без написания тестов.
> есть доказательства, что этот подход - самый эффективный из существующих?1. Проверка каждого оператора в коде - это лучше, чем отстуствие проверки.
2. А написание такой проверки ещё перед кодом - значит, что код будет делать именно то, что требуется проверкой, а не что-то другое.
> Сколько не
> видел попыток внедрения данного подхода - ни разу не было отмечено
> позитивных изменений, даже если разработка ведется вообще без написания тестов.Посмотрите литературу и видео Uncle Bob'а. Там всё подробно рассказано.
> написание такой проверки ещё перед кодомЭто называется "перенос сложности". Сложность системы остаётся неизменной, но можно перенести её с одного этапа на другой. В данном случае вы переносите сложность тестирования и отладки с этапа тестирования и отладки на этап написания предварительных тестов.
По личному опыту: это работает лишь в самых простых случаях. Когда в коде идёт выборка данных из БД или работа с оборудованием, то для повторения ситуации нужно повторить всю БД или её значительную часть.
Пример: построение сложного отчёта для нужд руководства компании, объединяющего данные о продажах и закупках в нескольких разрезах.
Отсюда вытекает, что твои тесты возможно лишь в простых функциях где есть чётко обозначенные вход и выход. В 90% случаев они настолько просты и понятны, что написание для них тестов - это потеря времени.
Unit тесты становятся интересными лишь в ситуациях где можно обеспечить "полное покрытие тестами" и нужно вносить много изменений во все модули. Такие ситуации встречаются редко.
>> написание такой проверки ещё перед кодом
> Это называется "перенос сложности". Сложность системы остаётся неизменной, но можно перенести
> её с одного этапа на другой.Оно и одержимое первых 7 метров /dev/random сложно, как и 7 метров /boot/vmlinuz-4.4.0-64-lowlatency
но в первом случае - такая фигня получается...
> В данном случае вы переносите
> сложность тестирования и отладки с этапа тестирования и отладки на этап
> написания предварительных тестов.Если нет тестов - то начинается дебаг, роль уровня владения дебаггером разработчика и временные затраты на сам дебаг - значительно возрастают с ростом проекта (посмотрите сколько уже инструментов run-time дебага в линухе)
Что лучше: один раз написать тест и получить постоянную проверку этого места кода, чем постоянно тратить время на дебаг?
Ведь тест то будет запускаться всегда уже автоматом, без доп. затрат времени.> По личному опыту: это работает лишь в самых простых случаях. Когда в
> коде идёт выборка данных из БД или работа с оборудованием, то
> для повторения ситуации нужно повторить всю БД или её значительную часть.А большие модули системы никак не должны работать вместе?
И пусть это уже называется не юнит-тестированием, а как-то иначе, но сути не меняет:
Вы ведь хотите, чтоб продукт всегда работал, а не только во время изначального написания кода? А как _убедиться_, что он работает? - А только протестировать.> Отсюда вытекает, что твои тесты возможно лишь в простых функциях где есть
> чётко обозначенные вход и выход. В 90% случаев они настолько просты
> и понятны, что написание для них тестов - это потеря времени.И после любого изменения начинается "экономия времени": открыть страничку логина, нажать кнопку, попробовать там ли всё работает...
И это нужно делать при каждом добавлении новой фичи или исправлении бага - иначе нет морального права утверждать, что вся программа работает.
Т.е. тестировать всё равно приходится. Но как быстрее: руками или автоматически, кодом?
> Unit тесты становятся интересными лишь в ситуациях где...должно работать, а не просто почасовая оплата ^_^
Зачем вы проецируете свой опыт веб-макаки на разработку ядра ?Вот почему все люди точно знающие как нам обустроить Россию уже работают в Макдональдсе ?
Внимательнейше слушаю Ваши предложения по решению проблем устойчивости и безопасности Линуха.
Системно, пожалуйста (т.е. не только в каких-то отдельных местах ядра).
> Вот почему все люди точно знающие как нам обустроить Россию уже работают
> в Макдональдсе ?А у Вас есть предложения как обустроить Россию? Где можно почитать?
Что думаете о подконтрольности ЦБ? о ростовщическом проценте? вреден/полезен/неважно?
И прочие важные вопросы - тоже интересуют (образование, наука, экономика и т.д.)
Обрататитесь к Шигорину, он знает.
> Обрататитесь к Шигорину, он знает.Да если бы. Поскольку в целом не знаю -- обустраиваю там, где знаю и умею.
20170223 1151
20170224 1154
20170225 1185
20170226 1186
20170227 1201
Нди на ... в ... нет всё таки - на другой сайт :)
> Что лучше: один раз написать тест и получить постоянную проверку этого места кода, чем постоянно тратить время на дебаг?Простые функции не нуждаются в unit-тестировании, сложные с помощью unit-тестов полностью не проверишь.
Идея о постоянной отладке одной и той же функции - это вообще откуда? Какой только бред не придумают чтобы втюхать своё фуфло...
> Ведь тест то будет запускаться всегда уже автоматом, без доп. затрат времени
Опять обман. Покрытие unit-тестами приводит к следующему этапу - сервер тестирования, который в цикле гоняет тесты один за другим, рассылая уведомления. Зачем вновь и вновь проверять одну и ту же неизменённую функцию одними и теми же тестами? Вопрос риторический.
> Вы ведь хотите, чтоб продукт всегда работал, а не только во время изначального написания кода?
А что, отлаженный код вдруг, сам по себе, перестаёт работать правильно и начинает сыпать ошибками?
Чаще возникает ситуация, когда что-то не учли. И эти ошибки обычно логические. Напр. функция должна возвращать должность сотрудника, но "забыли" про совместителей, которые работают на 2+ должностях. В результате неверно начислили зар.плату. Как написать unit-тест, чтобы он проверил данную ошибку?
> А что, отлаженный код вдруг, сам по себе, перестаёт работать правильно и начинает сыпать ошибками?Бывает и так, при изменениях в окружении в котором этот код выполняется.
Для примера можете почитать о ставшем классикой сбое в софте Ariane 5.
Их ошибка, что они использовали копи-пастнутый код, изменяющий глобальные переменные, не проверив его работоспособность и не разбираясь нужен ли он вообще (не нужен).Аналогичная ситуация произошла недавно в России: при старте первой ракеты с Восточного возникла ошибка, которая остановила запуск. Оказалось, что изменили один из блоков навигации: он был квадратным, стал круглым и с другим количеством контактов. Но те, кто собирал ракету, не сильно парились: они вбили его кувалдой, заизолировав "лишние" проводки.
Ошибку нашли, но решали проблему не менее оригинальным способом: они выломали модуль и спаяли проводки так, чтобы отсутствующий модуль всегда возвращал состояние "всё ОК".
Ну вот и как сплошной положизм на нормы характеризует собстенно сами нормы?
Ежегодным ростом количества падающих ракет. Как следствие, растёт стоимость страховки, так страховка за запуск спутника с российского Байконура стоит дороже, чем за запуск с американского Канавэрал, хотя сам запуск пока обходится дешевле.
Т.е. нормы таки указывают как суммарно дешевле вести дела... но чиновников это мало волнует, а налогоплательщика... похоже, ещё меньше.
Так и живём, вводя друг друга в заблуждение, дескать "всё контролируется"
> Простые функции не нуждаются в unit-тестированииА как тогда узнать как они работают и работают ли вообще?
Каждый раз код перечитывать и моделировать в уме? Заняться нечем?А вот такие функции (net/dccp/input.c:dccp_rcv_state_process) как?
Они простые или нет, нуждаются в тестировании или нет?см. git commit 5edabca9d4cff7f1f2b68f0bac55ef99d9798ba4
> сложные с помощью unit-тестов полностью не проверишь.Для этого есть интеграционные и системные тесты.
>> Простые функции не нуждаются в unit-тестировании
> А как тогда узнать как они работают и работают ли вообще?Дисциплина https://xkcd.com/1790/ функционального программирования! </решает!></да, на Си>
> Для этого есть интеграционные и системные тесты.
А как узнать, что код писанный по функц. программированию делает то, что нужно?
Кроме как проверить.
А как быстрее проверять: руками или авторматически?
продолжение следует...
Я закончил ответ в постах #159 и #160
(извините, специфика форума)
> А написание такой проверки ещё перед кодом - значит, что код будет делать именно то, что требуется проверкой, а не что-то другое.Тест гарантирует только то о чем подумал автор теста, и не более того.
Тем более от тестов нет никакого толку для кода взаимодействующего с железом.
> Тест гарантирует только то о чем подумал автор теста, и не более
> того.Другого и не утверждал.
Но без тестов, код куда больше делает и того, чего автор не планировал.
С тестами этого куда поменьше.> Тем более от тестов нет никакого толку для кода взаимодействующего с железом.
А вот это вот не так.
Микроядро обязано контроллировать доступ к железным портам (а потому, именно само будет звать всякие io/out инструкции, но вылизать этот небольшой и малоизменчивый код - не проблема). А вот дрова устройств, которые будут работать в отдельных процессах, - они будут вынуждены вызывать соотв. функции микроядра для доступа к собтвенно железу. И вот это вот разделение открывает прекрасные возможности для тестирования.
К примеру, если нужно, чтобы при вызове senddata(buffer) драйвер отправлял размер буфера и его самого по определённым железным адресам - то делается просто соотв. assert'ы в конце теста и всё. Код же самого драйвера - одинаков и для теста, и для реальной работы.
Чего и требовалось.
> Но без тестов, код куда больше делает и того, чего автор не планировал.Это утверждение ничем не обосновано.
Попробуйте посмотреть в багтрекеры проэктов без модульного тестирования.
И сравнить вероятность незапланированного поведения в случаях:
* когда код пишется сразу
* и когда код пишется лишь после написания теста, его проверяющего (т.е. кода без тестов не может появиться в проекте в принципе).
Вероятность одинакова, бо код пишется не роботами и ошибка равновероятно может быть как в коде, так и в тесте.Но вы можете продолжать верить в серебряные пули.
> Вероятность одинакова, бо код пишется не роботами и ошибка равновероятно может быть
> как в коде, так и в тесте.Безусловно. Тесты - это тоже код, и его пишут люди.
Но тесты контроллируют и былые ошибки, и быстро проверяют всю систему целиком вместе с новыми вносимыми правками. И вот роль истории усвоенных и поправленных ошибок код сам по себе контроллировать уже не может. Потому, вероятность безошибочности смещается туда, где есть и такой себе исторический контроль ошибок.
>> Тем более от тестов нет никакого толку для кода взаимодействующего с железом.
> А вот это вот не так.
> Микроядро обязано контроллировать доступ к железным портам (а потому, именно само будет
> звать всякие io/out инструкции, но вылизать этот небольшой и малоизменчивый код
> - не проблема).Дайте я угадаю, вы никогда не занимались низкоуровневым программированием на практике ?
> А вот дрова устройств, которые будут работать в
> отдельных процессах, - они будут вынуждены вызывать соотв. функции микроядра для
> доступа к собтвенно железу. И вот это вот разделение открывает прекрасные
> возможности для тестирования.ЧТО ВЫ СОБИРАЕТЕСЬ ТЕСТИРОВАТЬ ?!?!?
Вы понимаете что для тестирования драйвера вам фактически нужна стопроцентно корректная программная модель всех поддерживаемых драйвером железок со всеми их особенностями/аппаратными косяками/багами прошивок (иначе грош цена всем вашим тестам) ?
> К примеру, если нужно, чтобы при вызове senddata(buffer) драйвер отправлял размер буфера
> и его самого по определённым железным адресам - то делается просто
> соотв. assert'ы в конце теста и всё.Какая в конскую жoпy senddata() ? Куда send ? В i/o port, в mmio, в кольцевой буфер железки, в mailbox, КУДА ?
Ты понимаешь что ты пoexaвший ?!?!?!?!?
> ЧТО ВЫ СОБИРАЕТЕСЬ ТЕСТИРОВАТЬ ?!?!?Подсистемы ядра (всего того, что нонче есть в Линухе (в гит репе, если совсем быть точным)), в частности, драйвера (и железа, и ФС).
> Вы понимаете что для тестирования драйвера вам фактически нужна стопроцентно корректная
> программная модель всех поддерживаемых драйвером железок со всеми их особенностями/аппаратными
> косяками/багами прошивок (иначе грош цена всем вашим тестам)?Внезапно.
Будто для написания драйвера этого всего не нужно :)
Но дрова есть и их пишут - значит есть какие-то достаточные представления и о железках,
и вот эти представления, записанные в виде тестов - дадут гарантию, что драйвер делает то, чего захотел программер (и лишь в незначительной степени, чего он пропустил или допустил).
> Но дрова есть и их пишут - значит есть какие-то достаточные представления и о железках,Ну да programming manual и программная модель устройства (фактически его эмулятор) это конечно одно и тоже.
> и вот эти представления, записанные в виде тестов
Oбъем и сложность задачи представляете ? Bижу что нет.
А главное все это, только для того чтобы мамкины теоретики могли спокойно кушать свой борщ.
> Ну да programming manual и программная модель устройства (фактически его эмулятор) это
> конечно одно и тоже.Хоть одно, хоть нет.
А ответить на простой вопрос: а так ли работает драйвер, как задумывал сам автор драйвера? - в самом же драйвере нет.
Как-то предлагаете решать эту проблему?>> и вот эти представления, записанные в виде тестов
> Oбъем и сложность задачи представляете ? Bижу что нет.Когда нужно таки ответить на вышепоставленный вопрос - то вместо того, чтобы за пару секунд прогнать тесты, начинаетя поиск документации (в лучшем случае что-то есть в Documentation/*), и ручное изучение кода...
Человекочасы? - о чём вы! Время ведь сэкономилено на ненаписании тестов!
Теперь можно спокойно его тратить тоннами на ручной просмотр.
> А главное все это, только для того чтобы мамкины теоретики могли спокойно
> кушать свой борщ.Приятного аппетита.
> Какая.... senddata()?какая-нить drivers/net/..../...c:senddata()
да, абстрактная (а как иначе рассказать о множестве случаев, кроме как абстрактно?)> Куда send ? В i/o port,
> в mmio, в кольцевой буфер железки, в mailbox, КУДА ?Вы перечислили частности, у каждого драйвера - свои куда. И все эти куда могут быть прописаны в тестах и проверяться автоматически. Что драйвер именно туда и именно то и пытается отправить.
> Ты понимаешь что ты ....... ?!?!?!?!?
Поменьше эмоций, пожалуйста.
Ваши частности и детали не меняют общего вопроса.
> Вы перечислили частности, у каждого драйвера - свои куда. И все эти куда могут быть прописаны в тестах и проверяться автоматически.Возвращаемся к вопросу о стопроцентно корректной программной модели железа.
>> Вы перечислили частности, у каждого драйвера - свои куда. И все эти куда могут быть прописаны в тестах и проверяться автоматически.
> Возвращаемся к вопросу о стопроцентно корректной программной модели железа.Но зачем? Мы проверили, что драйвер посылает железу корректный с точки зрения спецификации запрос. Если железо в ответ ведёт себя как-то не так, то это уже вопрос из области пересечения этики драйверописателя с костылями и подпорками.
Совершенно верно.
(или же кривизны уже самой железки; да, оно иногда ломается)
Никуда не нужно возвращаться. Речи о полноценном моделировании железа нет.
Речь о том, чтобы записать в тесте те требования к драйверу, которые были найдены (если реверсили) или задизайнены (если производитель).
И тогда эти требования будут проверяться за доли секунды кем угодно, невзирая на железо.
Непроизвольно внести изменение, которое сломает что-то где-то в другой стороне модуля - будет невозможно.
В драйвере версии 1, в регистр X пишется 42.
В драйвере версии 2, в регистр X пишется 43.Вопрос: как определить не сломалось ли что нибудь в версии 2 ?
(должен отметить конструктив в разговоре! Спасибо)> В драйвере версии 1, в регистр X пишется 42.
> В драйвере версии 2, в регистр X пишется 43.
> Вопрос: как определить не сломалось ли что нибудь в версии 2 ?1. Работает ли код относительно железа - запустить на железе и прогнать ВСЕ функции (руками или ещё как)
2. Работает ли код относительно представлений авторов этого кода - запустить на любой системе тесты (автоматом, несравнимо быстрее, чем руками)Вопрос же соответствия тестов спецификации самой железки - на совести авторов. Это никуда не девается. Тесты - лишь защита авторов от своих собственных ошибок-опечаток.
Господи, да поймите же вы что среди проблем в разработке драйверов, ошибки/опечатки отнюдь не номер 1.Реальные проблемы низкоуровневого программирования:
- кривоватость самого железа/фирмвари, заставляющая городить воркэраунды, иногда весьма нетривиальные;
- несовпадение документации с реальностью, прорехи в документации и прочая errata;
- всяческие проблемы тайминга, состязания (в том числе и с участием железа) и т.п.Ничему из этого тесты помочь не в состоянии.
> Господи, да поймите же вы что среди проблем в разработке драйверов, ошибки/опечатки
> отнюдь не номер 1.
> Реальные проблемы низкоуровневого программирования:
> - кривоватость самого железа/фирмвари, заставляющая городить воркэраунды, иногда весьма
> нетривиальные;
> - несовпадение документации с реальностью, прорехи в документации и прочая errata;
> - всяческие проблемы тайминга, состязания (в том числе и с участием железа)
> и т.п.Да, железо - тоже коммерческие продукты, и тоже со сроками и катайцами на производстве.
Проблем хватает.
Но всё-же, железка она ж как-то работает. И призвание программера понять его работу (из спецификации+практики) и заставить ядро работать с ним.
> Ничему из этого тесты помочь не в состоянии.Тесты в состоянии ответить на вопрос: соответствует ли код драйвера представлениям программиста о том, как оно должно работать (по его же мнению). Может он где-то сам ошибся - то его же тесты его же и поправят.
>> Ничему из этого тесты помочь не в состоянии.
> Тесты в состоянии ответить на вопрос:Нет.
Вам столько явно грамотных людей уже написало, что можно было пойти и прочитать про синдром Даннинга-Крюгера самостоятельно :(
Поймите -- все эти благопожелания имеют строго отрицательную ценность, поскольку лишь гробят время людей. Надо -- кайло в руки и делайте без отмазок вроде "ранний этап исследований": на раннем этапе производится литературный поиск и пролопачивается _уже_ опубликованная гора литературы и кода. "Не могу" -- значит, надо учиться. Выясняется, что не настолько и надо -- значит, нечего было пустозвонить про "призвание" и протчая.
> Вам столько явно грамотных людей уже написало, что можно было пойти и
> прочитать про синдром Даннинга-Крюгера самостоятельно :(Извините, но они свои грамоты в нет на обозрение не выставляли.
А потому - их слово не весомее чьего-либо.
> Поймите -- все эти благопожелания имеют строго отрицательную ценность, поскольку лишь гробят
> время людей. Надо -- кайло в руки и делайте без
> отмазок вроде "ранний этап исследований":Ну вот, снова. Указки ЧТО ДЕЛАТЬ.
Что делать я и сам решу, спасибо.
Я об этом помощи не просил.Куда интереснее обсуждать без эмоций как ДОЛЖНО БЫТЬ.
Но это не многим психологически по силам...
> на раннем этапе производится литературный поиск
> и пролопачивается _уже_ опубликованная гора литературы и кода.Извините, но мы не в оторванных от жизни высших кабинетах.
Мне нужно чтоб работало, а не где-то громко звучало.
> -- значит, нечего было пустозвонить про "призвание" и протчая.Не знаю с кем Вы и где попутали меня. Про призвания я нигде не говорил. Мои призвания - дело сугубо моё.
Вобщем, пост снова обо мне, а не о проблемах ядра... классика жанра. Все любят "лечить"...
>> -- значит, нечего было пустозвонить про "призвание" и протчая.
> Не знаю с кем Вы и где попутали меня. Про призвания я нигде не говорил."призвание программера" в #286 кто-то другой написал?
> Вобщем, пост снова обо мне, а не о проблемах ядра... классика жанра.
Видите ли, я как комодератор вынужден дать оценку Вашим сообщениям в плане того, не нарушают ли они правил форума -- см. http://wiki.opennet.ru/ForumHelp -- и пока стрелка всё больше склоняется к риске "бессодержательно".
Представьте себе, что Вы как (скажем) автомеханик на профильном форуме наткнулись на меня, который с умным видом рассказывает, что всем надо давно переходить на роторные двигатели, они ведь такие клёвые и столько проблем этого поршневого старья решают. Слегка офигеваете, бережно прощупываете -- это такой влюблённый в конкретную технологию по опыту человек или просто обку... обчитавшийся какой педивикии оболтус, который ни в зуб ногой, но туда же в калашный ряд. А оболтус всё не унимается и в ответ на аккуратные намёки разных участников форума только убеждается в собственной правоте, нисколечко при этом не выказывая желания пойти к верстаку и доказать её делом. Неприятно, правда?
> "призвание программера" в #286 кто-то другой написал?Да, моё. Спасибо.
Да, считаю, что программер должен разбираться в том, что пишет.
> Видите ли, я как комодератор вынужден дать оценку Вашим сообщениям в плане
> того, не нарушают ли они правил форума -- см. ....
> и пока стрелка всё больше склоняется к риске "бессодержательно".А вот это уже - сугубо Ваше право.
Я прекрасно осознаю и видел это не раз, когда громадными гроздьями исчезала переписка здесь, в каментах.Но если на техническом форуме обсуждение плюсов-минусов реализации того или иного дизайна ядра ОС это "бессодержательно"... видимо, обтереть друг друга людям куда важнее. Что ж, таковы люди.
> Представьте себе, .....пойти к верстаку и
> доказать её делом. Неприятно, правда?Кому и что нужно доказывать??
Я спрашиваю мнения о путях решения системных проблем Линуха и предлагаю своё решение.
Не, нельзя так?
Надо обязательно потратить сначала кучу времени, сделать 10 неудачных заходов, и лишь потом выйти "в люди", чтоб узнать кто что думает и знает об этой проблеме?
Извините, но я ценю своё время.
>> "призвание программера" в #286 кто-то другой написал?
> Да, считаю, что программер должен разбираться в том, что пишет.А там было про железку: "Но всё-же, железка она ж как-то работает. И призвание программера понять его работу (из спецификации+практики)".
> Но если на техническом форуме обсуждение плюсов-минусов реализации того или
> иного дизайна ядра ОС это "бессодержательно"... видимо, обтереть друг друга
> людям куда важнее. Что ж, таковы люди.Вы же не предложили никакого дизайна -- ни того, ни иного. И кода не вижу. А вижу благие пожелания и неумение следить за своей собственной мыслью на протяжении нескольких комментариев, увы.
Поймите, нет цели Вас "замочить". Но если на дорогу выпускать людей, которые путаются в педалях -- жди беды.
>> Представьте себе, .....пойти к верстаку и доказать её делом. Неприятно, правда?
> Кому и что нужно доказывать??Да хотя бы себе для начала.
> Я спрашиваю мнения о путях решения системных проблем Линуха и предлагаю своё решение.
> Не, нельзя так?Нельзя флудить попусту.
> Надо обязательно потратить сначала кучу времени, сделать 10 неудачных заходов,
> и лишь потом выйти "в люди", чтоб узнать кто что думает и знает об этой проблеме?
> Извините, но я ценю своё время.А я ценю время обсуждающих. И, как ни странно, своё.
На этом и предлагаю завершить эту "гроздь".
> А там было про железку:....Верно. Считаю, что лучше понять как работает железка, чтобы написать её драйвер.
Да, спасибо за внимание
>Какая в *** senddata() ? Куда send ?Я ожидал от микроядерного пророка ответ "data" :)
Ну так и обратитесь тогда к пророку.
А я да - спасибо, на будущее буду расписывать тесты в более конкретной форме.
>Тест гарантирует только то о чем подумал автор теста, и не более того.Тест написанный по спецификации повышает уверенность в том, что система ведёт себя в соответствии с данной спецификацией. Тест написанный разработчиком в рамках test-driven development сам становится спецификацией т.к. отражает видение автора и помогает понять его код.
>Тем более от тестов нет никакого толку для кода взаимодействующего с железом.
Это заблуждение. При должном желании и ресурсах можно эффективно протестировать любую программу вне зависимости от того что она делает и как она написана. Поместить модули в тестовое ложе для модульного или интеграционного тестирования, написать эмулятор железа, создать автоматическую систему для сборки и тестирования системы на разных конфигурациях. Главная проблема обычно заключается в отсутствии хорошей спецификации на систему и в том факте, что её основные разработчики умерли или загремели в дурку.
Вопрос в том - а нужно ли это? Затраты на тестирование должны слихвой покрываться предотвращёнными убытками от найденных багов.
Вас маркетологи покусали ?
> Тест написанный по спецификации повышает уверенность в том, что система ведёт себя
> в соответствии с данной спецификацией. Тест написанный разработчиком в рамках test-driven
> development сам становится спецификацией т.к. отражает видение автора и помогает понять
> его код.Спецификацией так и остаётся текстовое описание дизайнеров железки. Набор же тестов - это видение разработчиков, но никак не дизайнеров.
> Это заблуждение. При должном желании и ресурсах можно эффективно протестировать любую программу
> вне зависимости от того что она делает и как она написана.
> Поместить модули в тестовое ложе для модульного или интеграционного тестирования,Да, и идеально, если и тестируемый код, и код в реальной работе - один и тот же.
> написать эмулятор железа
В случае, если все участки работы с железными портами уже заранее вынесены в отдельную систему (в микроядро) - эмулятор уже не требуется. Сами тесты могут контроллировать (предоставляя API микроядра) что и как вызывает код.
> Вопрос в том - а нужно ли это? Затраты на тестирование должны
> слихвой покрываться предотвращёнными убытками от найденных багов.Убытки так или иначе распределены по всей Земле. Их посчитать трудно (хотя можно на примере частной какой-то выборки прикинуть).
В конечном же итоге, вопрос лишь в том: есть ли кто-то, кто озабочен проблемами всех?
Благо, такие есть.
> В случае, если все участки работы с железными портами уже заранее вынесены
> в отдельную систему (в микроядро) - эмулятор уже не требуется. Сами
> тесты могут контроллировать (предоставляя API микроядра) что и как вызывает код.И что толку ? Разработчик (прочитав мануал) считает что нужно писать 42 в регистр X, затем 322223 в регистр Y, тесты проходятся, драйвер не работает.
И как теперь оленя пасти ?
Менять тесты. Ведь они - просто закодированное желание автора.
Он хочет, чтоб не работало - так и запишет.
Если ему не понравится результат - он изменит тесты и посмотрит на новый.
> И что толку ? Разработчик (прочитав мануал) считает что нужно писать 42
> в регистр X, затем 322223 в регистр Y, тесты проходятся, драйвер
> не работает.
> И как теперь оленя пасти?А здесь требуется анализ - почему не работает. Может быть глюк в железе, может быть представление автора о работе этого железа неправильное, может быть покрытие тестами недостаточное, а может быть тесты - бесполезная лажа.
> а может быть тесты - бесполезная лажа.А может и защита от своих же опечаток - это тоже лажа.
У каждого свой уровень.
> Спецификацией так и остаётся текстовое описание дизайнеров железки. Набор же тестов -
> это видение разработчиков, но никак не дизайнеров.В моей области и код и тесты пишутся по спецификации. Спецификация - учитывает требования заказчика, пользователей, индустрии. Если видение разработчиков расходится со спецификацией и это не вызвано проблемой в спецификации, то разработчики переписывают код.
> В случае, если все участки работы с железными портами уже заранее вынесены
> в отдельную систему (в микроядро) - эмулятор уже не требуется. Сами
> тесты могут контроллировать (предоставляя API микроядра) что и как вызывает код.Написать эмулятор выйдет в миллионы раз дешевле, чем переписывать архитектуру такой огромной системы, как Линукс.
> Если видение разработчиков
> расходится со спецификацией и это не вызвано проблемой в спецификации, то
> разработчики переписывают код.Однозначно.
Вопрос лишь в выявлении возможных несоответствий (которые возможны, ведь тесты и спецификация на людском языке - всё-таки разные документы).
> Написать эмулятор выйдет в миллионы раз дешевле, чем переписывать архитектуру такой огромной
> системы, как Линукс.Да. Но раздельные адресные пространства для самих дров линуха - такой эмулятор не даст.
Более простая тестируемость - это же лишь следствие микроядра.
Вас маркетологи покусали ?
> Кто-то ещё сомневается, что Линуксу давно пора менять дизайн на микроядро?
> Это ж оно в сабже просто не скомпилилось у Торвальдса. А если
> бы скомпилилось? Но никакого тестирования то там всё так же и
> не было...И? Если у кого-то не было желания тестировать свой код (в том числе и писать тесты), то почему вдруг при изменении архитектуры что-нибудь поменяется?
> Да и сейчас, в монолитном виде тестировать отдельные модули ядра, кроме как
> собрать ВСЁ, загрузить и погонять - некак. (а хоть какие-то тесты
> есть только в btrfs модуле)
> Остаётся не у дел самый эффективный подход - разработка через тестирование. Причём,
> в самой критичной части операционки...
> Микроядерный же подход позволяет имитировать микроядро для модуля, и делая контрольные
> вызовы - контроллировать что модуль зовёт дальше: есть ли нужные обращения
> к железу (через выховы микроядра) и прочим сервисам.Ну вообще-то и в текущем ядре это сделать не проблема, микроядро здесь скорее все усложнит. Есть скажем штуки 3 функции для записи регистров устройств (байт, два байта, 4 байта), переопредели их и вот ты контролируешь работу с железом.
API ядра которое использует DRM тоже считанные функции,в общем переопределив штук 30 функций можно полностью котролировать драйвер и
писать для него тесты, другой вопрос чтоа)Это скучно и не интересно писать тесты, как здесь поможет какая-либо другая архитектура?
б)Набор функций маленький, но количество комбинация их вызовов и соотвественно
объем тестирования огромный, как здесь опять может какая-либо другая архитектура?> Ну и излишне говорить о безопасности, даже если какая ошибка вкрадётся в
> какой сервис - это всё-таки, уже отдельный процесс. Даже если навернётся
> - то будет просто перезапущен. Всё остальное продолжит работу.
> в общем переопределив штук 30 функций можно полностью котролировать драйвер иписать для него тесты
И что вы собираетесь таким образом тестировать ?
> И? Если у кого-то не было желания тестировать свой код (в том
> числе и писать тесты), то почему вдруг при изменении архитектуры что-нибудь
> поменяется?Если появляется возможность - то под давлением давних проблем, ею начнут пользоваться.
Хотя да, это просто открытая возможность, ни к чему не обязывающая.
Даже если продолжать писать код, как счас - всё равно система будет куда стабильнее.
>> Да и сейчас, в монолитном виде тестировать отдельные модули ядра, кроме как
>> собрать ВСЁ, загрузить и погонять - некак. (а хоть какие-то тесты
>> есть только в btrfs модуле)
>> Остаётся не у дел самый эффективный подход - разработка через тестирование. Причём,
>> в самой критичной части операционки...
>> Микроядерный же подход позволяет имитировать микроядро для модуля, и делая контрольные
>> вызовы - контроллировать что модуль зовёт дальше: есть ли нужные обращения
>> к железу (через выховы микроядра) и прочим сервисам.
> Ну вообще-то и в текущем ядре это сделать не проблема, микроядро здесь
> скорее все усложнит.Сейчас, чтобы протестировать работу драйвера (не уронив саму систему, где идёт разработка) нужно:
сделать так, чтоб драйвер компилился на уровне пользователя
добавить каких-нить заглушек на оконечную работу модуля с железом
и уже собсно, автоматически тестировать (на основе контроля правильности вызова этих заглушек).
Микроядро же - сразу даёт первых 2 пункта в готовом виде.Ну практически полная аналогия если сравнивать написание модуля под монолит и разработка обычной юзер-левел проги.
> Есть скажем штуки 3 функции для записи регистров
> устройств (байт, два байта, 4 байта), переопредели их и вот ты
> контролируешь работу с железом.Да, и это нужно делать всем разработчикам железодров, каждый по-своему.
Или может один раз это сделать займёт меньше времени? (те самые линуксовые человеко-часы)> другой вопрос что
> а)Это скучно и не интересно писать тесты, как здесь поможет какая-либо другая
> архитектура?
> б)Набор функций маленький, но количество комбинация их вызовов и соотвественно
> объем тестирования огромный, как здесь опять может какая-либо другая архитектура?Дрова часто (не всегда) пишут те, кто проэктировал железку, т.е. они и так знают как и на какие команды она должна реагировать. По сути, тесты уже есть (вопрос формата).
А насчёт скучно - так рутовая уязвимость в левой пятке ненужного драйвера на нескольких тысячах серваков с юзерским ssh доступом - завсегда прибавит веселья.
И так раз в год-полгода СТАБИЛЬНО. И просвета в монолитом НЕ ВИДАТЬ.
> Сейчас, чтобы протестировать работу драйвера (не уронив саму систему, где идёт разработка)
> нужно:
> сделать так, чтоб драйвер компилился на уровне пользователя
> добавить каких-нить заглушек на оконечную работу модуля с железом
> и уже собсно, автоматически тестировать (на основе контроля правильности вызова этих заглушек).
> Микроядро же - сразу даёт первых 2 пункта в готовом виде.
> Ну практически полная аналогия если сравнивать написание модуля под монолит и разработка
> обычной юзер-левел проги.Для ядра в user space есть архитектура "um", и еще конечно qemu,
так что первые 2 пункта и для Linux есть том же относительно готовом виде.> Дрова часто (не всегда) пишут те, кто проэктировал железку, т.е. они и
> так знают как и на какие команды она должна реагировать. По
> сути, тесты уже есть (вопрос формата).Блин, почитайте про юнит тесты и multithreading,
а прерывания (которые используют практически любая железка)
дают тот же эфект внезапного переключения контекста,
все еще думаете что это легко написать тест который реально что-то тестирует?
> Для ядра в user space есть архитектура "um", и еще конечно qemu,Проброс железки "внутрь" - задача может и простая, но не решает поставленный вопрос:
тестировать модуль этой железки (который просто будет бежать внутри um/qemu)> так что первые 2 пункта и для Linux есть том же относительно
> готовом виде.Попробуйте пробросить что-нить эдакое в qemu или найти тот же драйвер, если конфигурите ядро под ARCH=um. Да, его там просто может не быть (т.к. драйвер может зависеть от конкретного множества аппаратных архитектур). Т.е. решение - не универсально.
> Блин, почитайте про юнит тесты и multithreading,Готово. И?
"Трудно == не надо делать"?> а прерывания (которые используют практически любая железка)
> дают тот же эфект внезапного переключения контекста,
> все еще думаете что это легко написать тест который реально что-то тестирует?Покажите мне где я упоминал слово "легко".
>> Для ядра в user space есть архитектура "um", и еще конечно qemu,
> Проброс железки "внутрь" - задача может и простая, но не решает поставленный
> вопрос:
> тестировать модуль этой железки (который просто будет бежать внутри um/qemu)
>> так что первые 2 пункта и для Linux есть том же относительно
>> готовом виде.
> Попробуйте пробросить что-нить эдакое в qemu или найти тот же драйвер, если
> конфигурите ядро под ARCH=um. Да, его там просто может не быть
> (т.к. драйвер может зависеть от конкретного множества аппаратных архитектур). Т.е. решение
> - не универсально.Что-то вы оба отдаляетесь от контекста обсуждения:
о том насколько легко разработчику драйвера написать тесты в Linux vs мифическая микроядерная ОС.
ИМХО, микроядерная ОС ничем не поможет,
и в том и в другом случае есть довольно небольшой API между драйвером и ОС.
Т.к. хотя ядро Linux это и монолит, но это не значит что как программа оно плохо
спроектировано, модульность и инкапсуляция там везде применяются.То в каком адресном пространстве будет запускаться тест совершенно не скажется на том, просто будет тест написать или нет.
И с современными технологиями виртуализации и возможности отладки теста будут одинаковы.
А вот сторону эмулирующее микроядро и сервисы и железо vs ядро и железо надо будет писать в обоих случаях. Потому что какой это нафиг юнит тест, если для его запуска нужно запустить всю остальную программу, это уже функциональный тест получается.
> ИМХО, микроядерная ОС ничем не поможет,
> и в том и в другом случае есть довольно небольшой API между
> драйвером и ОС.Да, согласен.
> Кто-то ещё сомневается, что Линуксу давно пора менять дизайн на микроядро?
> PS Минусующим просьба: пишите словами против чего именно Вы против.Мы за. Просто ты не понимаешь. Торвальдсу платит ЛФ. Решение -- стань членом ЛФ и _занеси_ им достаточную для _твоих_ хотелок сумму. И всё! Они ж опенет не читают, они отчёты своего отдела продаж читают.
Ву компроне, ситуайен? Ffffморфируй же.
> Мы за.Ну так это уже ж хорошо.
> Просто ты не понимаешь. Торвальдсу платит ЛФ. Решение -- стань
> членом ЛФ и _занеси_ им достаточную для _твоих_ хотелок сумму. И
> всё! Они ж опенет не читают, они отчёты своего отдела продаж
> читают.Вы счас расписали процесс реализации идеи, которая НЕ овладела массами. Да, за реализацию таких идей приходится платить.
Но у меня другой путь: я за просвещение масс, чтоб люди поняли где решение их проблем.
И тогда корпорации, которые пытаются хорошо выглядеть перед потребителем, неизбежно будут вынуждены менять курс, согласно масовому пониманию.
>> Мы за.
> Ну так это уже ж хорошо.#>>ситуайен? Ffffморфируй же.
А вот и По, пришедший за мной. </надо ставить таги></надо ставить таги></надо ставить таги>
>процесс реализации идеи, которая НЕ овладела массами.
Пациент: — Но вы, доктор, тоже ведь сексуальный маньяк? Признайтесь? Доктор: — С чего вы взяли? Пациент: — А откуда у вас такие картинки?
>я за просвещение масс
>корпорации, которые пытаются хорошо выглядеть перед потребителем
Что-то слишком много тегов...
> Да и сейчас, в монолитном виде тестировать отдельные модули ядра, кроме как
> собрать ВСЁ, загрузить и погонять - некак. (а хоть какие-то тесты
> есть только в btrfs модуле)Сразу видно микроиксперда. Зачем пересобирать ВСЁ, если можно пересобрать только тестируемый модуль и выгрузить/загрузить его в работающее ядро?
Согласен, криво выразился.
Писать один модуль, конечно, можно только его пересобирать-перегружать.
Но вот для релиза всего ядра с этим модулем - придётся тестировать и множественной сборкой на случайных конфигах.
Давайте вы свои кривые ручонки к линуксу тянуть не будете, а стройными и могучими рядами пойдёте на^W пилить свой хурд. Или что там нынче в коворкингах модно обсуждать.
Как там у классика: не указывайте мне что делать, и я не буду говорить куда....
Почему вы тогда считаете для себя возможным указывать что должны делать разработчики ядра ?"Видно только профессорам разрешается ругаться в ресефесере."
> Почему вы тогда считаете для себя возможным указывать что должны делать разработчики ядра ?Вы меня с кем-то путаете. Я ничего такого никому не указывал.
Каждый делает что хочет.Но я (равно как и Вы, и другие) вправе иметь мнение о работе каждого. А также - высказывать это мнение на публичных форумах.
> Но я (равно как и Вы, и другие) вправе иметь мнение о работе каждого.А сами в это время наглотались зубного порошку.
вправе ровно до тех пор, пока это не нарушает чужих прав
> вправе ровно до тех пор, пока это не нарушает чужих правОбщеизвестно.
Но Вы то намекаете, что эти чужие права мной уже попраны?
Детали, пожалуйста. Где и в чём попраны?
Молодец, Линус! Всё сделал правильно! Я вот от Дейва такого не ожидал. Не первый год DRM мейнтейнит, и такое....
> Молодец, Линус! Всё сделал правильно! Я вот от Дейва такого не ожидал.
> Не первый год DRM мейнтейнит, и такое....Может он "в git" не смог?... Может его libv http://libv.livejournal.com/27799.html расстроил?...
Ничего страшного, Линус порешал уже -- всё ж, буквально всё!, уже исправлено. Не надо беспокоиться. </модель работает>
> Ничего страшного, Линус порешал уже -- всё ж, буквально всё!, уже исправлено.
> Не надо беспокоиться. </модель работает>и что было сделано, чтобы исключить подобное в будущем? а, ничего? погавкал-полаял, как обычно, но ничего не изменил, до следующих граблей
> и что было сделано, чтобы исключить подобное в будущем? а, ничего? погавкал-полаял,
> как обычно, но ничего не изменил, до следующих граблейНу Вы то - не он. У Вас то есть предложения.
Изложите?
> но ничего не изменил, до следующих граблейКому-то уже предлагали патчи на ДНК...
Кстати. Кто есть в официальном баг-трекере? Запостите, пожалуйста:../drivers/gpu/drm/i915/i915_gem_gtt.c: In function 'gen6_ggtt_insert_entries':
../drivers/gpu/drm/i915/i915_gem_gtt.c:2438: error: 'gtt_entry' may be used uninitialized in this function
../drivers/gpu/drm/i915/i915_gem_gtt.c: In function 'gen8_ggtt_insert_entries':
../drivers/gpu/drm/i915/i915_gem_gtt.c:2341: error: 'gtt_entry' may be used uninitialized in this function
make[6]: *** [drivers/gpu/drm/i915/i915_gem_gtt.o] Error 1
make[5]: *** [drivers/gpu/drm/i915] Error 2Вёдра 4.9.0-4.9.8 включительно, новее пока не проверил. Компилятор GCC 4.3, дистр SLES 11. С более новыми компиляторами всё собирается. 4.3 же ещё не дропнули, верно?
>GCC 4.3Как там в 2009 живётся?
Windows 7 недавно вышла, на нетбуках не тормозит, просто чудо. Кажется, Red Hat с Canonical поняли что вeндeкaпeц они сделать не успели. И послали в задницу GNOME2. Надеюсь, его кто-нибудь форкнет.
Да-да. Я как раз где-то год спустя покупал нетбук. Попросил в магазине показать систему. Винда самонастраивалась минут 10. В итоге я купил нетбук на Meego и поставил на него Crunchbang (сейчас на нем CentOS). Вот он-то действительно не тормозит (если не использовать жирнофокс).
Жанна купил ноутбук и random'но ставил все ОС что под руку попадались.
"Выступил с критикой" это мягко сказано. Обматерил сразу всех причастных в drm-драйверам.
CI для слабаков?
> CI для слабаков?Для микроядра тоже - автоматом тестить крайне неудобно (а потому и практически не тестят)
> CI для слабаков?Оплачивать электричество для CI для слабаков. Смержил - да и в пулл-реквестик! </кто-кто не смог в гит?>
> Оплачивать электричество для CI для слабаков.
>электричествоОй.
"By 2005, there are quite a few datacenters that are limited by electrical power rather than by floor space. So much so that large data centers open in Eastern Oregon, on the sites of the old aluminum smelters. When you have that many servers, even a few percent of energy savings translates to millions of dollars a year, which is well worth spending some development effort on.
[,,,]
These plans include the use of formal verification in your regression test suite." --http://paulmck.livejournal.com/46439.html
Неужели эта Mesa 13.0.5/17.0.0 (dri, libGL) так отвратно портируется в Linux? Дожили.
> Неужели эта Mesa 13.0.5/17.0.0 (dri, libGL) так отвратно портируется в Linux? Дожили.ты drm перепутал с месой
>> Неужели эта Mesa 13.0.5/17.0.0 (dri, libGL) так отвратно портируется в Linux? Дожили.
> ты drm перепутал с месойКак ты запустишь новую Mesa на глючной drm, объясни? Люди старались, делали свободную реализацию 3D для Linux, а в ядре ответная часть такая... кака.
Мезу и DRM для линукса делают одни и те же люди. Так что еще не понятно, как они там старались, если в ядре кака получилась.
> раскритиковал Дэвида Эйрлитого самого чудака, которого когда-то не приняли в АМД и он не пропускает DC в Linux, тоесть блочит Freesync и HDMI-audio на новых картах АМД. Интересно после критики Линуса, пропстит патчи или нет, заиграет чувство вины =)
Надеюсь что этот DC никогда не пропустят. Скрещивать ужа с ежом изначально плохая идея.
Линукс закончится вместе с Линусом.
> Линукс закончится вместе с Линусом.А вот этого как раз и нельзя допустить. Хотя этого уже и не произойдёт - уже немало классных мейнтейнеров.
> уже немало классных мейнтейнеровВот таких вот?
На самом деле не умрёт, но исключительно через корпоративные интересы.
> Вот таких вот?Надеюсь, поисковики Вас не заблочили и список сможете найти.
> На самом деле не умрёт, но исключительно через корпоративные интересы.
А что, корпорации тоже хотят работать.
И в том, кстати, гениальность Столлмана и его GPL: заставить их ещё и возвращать свои наработки с сообщество СПО.
когда про systemd будет сказано и переписано с нуля все?
Линусу надо было не орать матом, а забрать полномочия у обосравшегося. Но похоже с кадровым резервом дела совсем плохи.
Ну вот если повторится - заберёт. Это ни разу не первый случай, когда он матом орал - обычно до адресата доходило
ответ к #87// Идея о постоянной отладке одной и той же функции - это вообще откуда?//
Вот глючит громааадный бинарь (типа опенофиса или монолит-линуха). Ваши действия?
Дебагить. А одна и та же функция может вызываться N+500 раз в разных местах, и по ней придётся ходить дебагером (хоть и не хочется).
И вполне возможно, что в каком-то случае окажется, ведёт она себя неправильно.
в продолжение к ответу на #87> Опять обман. Покрытие unit-тестами приводит к следующему этапу - сервер тестирования, который
> в цикле гоняет тесты один за другим, рассылая уведомления. Зачем вновь
> и вновь проверять одну и ту же неизменённую функцию одними и
> теми же тестами? Вопрос риторический.Чтобы знать, что она работает ВСЕГДА, при ЛЮБЫХ изменениях во всём проекте.
Нет никакого другого пути ДОКАЗАТЬ, что код работает, кроме как протестировать его (руками или автоматом - но что быстрее?). А если что-то изменилось - то это уже другой код, который также нуждается в таковом доказательстве.
Для сравнения, чтобы понять зачем нужно доказательство работы кода:
(вопрос для СЕБЯ, а не чтобы отвечать на него другим)
Доверяете ли Вы своему коду так же, как парашюту во время прыжка с самолёта?
> А что, отлаженный код вдруг, сам по себе, перестаёт работать правильно и
> начинает сыпать ошибками?Всегда есть, как минимум, список новых хотелок от пользователей. И их приходится реализовывать, т.е. МЕНЯТЬ код. И после любого изменения - он автоматически теряет статус отлаженного, т.к. не было ни проверок, ни обкаток его в таком виде (а что и какой пяткой можно зацепить в большой системе, изменив лишь строчку - не всегда можно догадаться; да, программист - это не всезнающий Бог).
Итого: поменялся код - нужно заново выяснить ВСЁ ли работает.
Иначе это будут выяснять либо тестировщики, либо бета-тестеры, либо конечные пользователи.
Выбирать - разработчикам (что говорит об уровне их профессионализма).
> Чаще возникает ситуация, когда что-то не учли. И эти ошибки обычно логические.
> Напр. функция должна возвращать должность сотрудника, но "забыли" про совместителей, которые
> работают на 2+ должностях. В результате неверно начислили зар.плату. Как написать
> unit-тест, чтобы он проверил данную ошибку?2 разных теста: звать ф-цию в двух разных условиях, которым она должна отвечать.
И тогда она будет отвечать им ВСЕГДА (а если нет - _программист_ увидит CI отчёт о сломанном тесте).
Всё просто.
Никак не пойму фанатов микроядра.
1. Хотите микроядро - пишите. Даже можете к уже существующим проектам присоединиться.
2. Нет знаний/умений писать - собирайте средства (деньги, оборудование) нанимайте спецов.
3. Нет ни денег не знаний, только орать горазды - собирайте митинги, требуйте от правительства
введения налога на "не пользование микроядром", деньги направляйте во второй пункт.
> Никак не пойму фанатов микроядра.
> 1. Хотите микроядро - пишите. Даже можете к уже существующим проектам присоединиться.Есть задачи, с которыми в одиночку не справиться. В таком случае следует предлагать свою идею другим людям в надежде найти единомышленников и конструктивную критику идеи.
> 2. Нет знаний/умений писать - собирайте средства (деньги, оборудование) нанимайте спецов.
Да, знать всё невозможно.
Но как деньги могут заменить отсутствие знаний? Чтобы обрести знания - их нужно обретать. Найм спеца не даст знаний. В лучшем случае придётся лишь слушать его лекции.> 3. Нет ни денег не знаний, только орать горазды - собирайте митинги
Есть ещё варианты. Собсно, описано в 1-ом пункте.
>> 1. Хотите микроядро - пишите. Даже можете к уже существующим проектам присоединиться.
> Есть задачи, с которыми в одиночку не справиться. В таком случае следует
> предлагать свою идею другим людям в надежде найти единомышленниковВо-первых, проекты давно есть. Во-вторых, "свою идею" продуктивней предлагать в виде хотя бы наброска. Иначе как-то это всё болтологией попахивает.
>> Есть задачи, с которыми в одиночку не справиться. В таком случае следует
>> предлагать свою идею другим людям в надежде найти единомышленников
> Во-первых, проекты давно есть.Микроядреный Линукс? Хоть один, прошу, ссылочку. Сам не нашёл.
> Во-вторых, "свою идею" продуктивней предлагать в виде
> хотя бы наброска. Иначе как-то это всё болтологией попахивает.Попахивать оно может чем угодно.
Но у любого проекта есть исследовательский этап. И именно в его рамках я вижу полезным поговорить с народом на тему. Чтоб знать что делать дальше.
>>> Есть задачи, с которыми в одиночку не справиться. В таком случае следует
>>> предлагать свою идею другим людям в надежде найти единомышленников
>> Во-первых, проекты давно есть.
> Микроядреный Линукс? Хоть один, прошу, ссылочку. Сам не нашёл.Debian GNU/Hurd.
Линукс, пожалуйста.(Debian GNU/Hurd уже и так в виртуалке крутится)
> (Debian GNU/Hurd уже и так в виртуалке крутится)Ну и как? *шёпотом
Пора переходить?
> Пора переходить?Всё бы всем лишь бы переходить, а не улучшать то, что есть...
> Debian GNU/Hurd.ага, это такой линукс
специалисты опеннетовские, одной фразой...
>>> Есть задачи, с которыми в одиночку не справиться. В таком случае следует
>>> предлагать свою идею другим людям в надежде найти единомышленников
>> Во-первых, проекты давно есть.
> Микроядреный Линукс? Хоть один, прошу, ссылочку. Сам не нашёл.Микроядерные. Линукс бывает экзоядерный, например. :)
>> Во-вторых, "свою идею" продуктивней предлагать в виде
>> хотя бы наброска. Иначе как-то это всё болтологией попахивает.
> Но у любого проекта есть исследовательский этап.Предъявите наработки, пожалуйста. Хотя бы план исследований. Хоть целеполагание с обоснованием.
>> 1. Хотите микроядро - пишите. Даже можете к уже существующим проектам присоединиться.
> Есть задачи, с которыми в одиночку не справиться. В таком случае следует
> предлагать свою идею другим людям в надежде найти единомышленников и конструктивную
> критику идеи.идейных у нас полно, мамаша. с реализаторами жопа.
> Да, знать всё невозможно.
> Но как деньги могут заменить отсутствие знаний? Чтобы обрести знания - их
> нужно обретать. Найм спеца не даст знаний. В лучшем случае придётся
> лишь слушать его лекции.золотые слова, два логина на курсеру этому господину! действительно лучший вариант. послушаете лекции, подучитесь, начнете сами проектировать и ваять то, что вам нужно.
> Есть ещё варианты. Собсно, описано в 1-ом пункте.
во втором. там, где про лекции.
> идейных у нас полно, мамаша. с реализаторами жопа.В основной массе за сегодня выслушал лишь одну основную идею:
"ты - не я, а, значит, неправ"Тяжело средь всего этого выудить что-то по сути...
> действительно лучший вариант. послушаете
> лекции, подучитесь, начнете сами проектировать и ваять то, что вам нужно.Ну собственно вот, опять...
Указыателей ЧТО ДЕЛАТЬ - тоже много. А вот обсудить без эмоций КАК ДОЛЖНО БЫТЬ в итоге - этого встретил пока мало...
Все резво рвутся (а равно указывают другим) сразу что-то писать. Что - неважно, главное писать. Немедленно. Иначе и обсуждать мало кто хочет.
А ничего, что перед тем как писать, лучше подумать и обсудить?
Потому как без обсуждения - то и получается, что каждый держит какой-то заброшенный гитхаб репу с оертаниями какого-то поделия, а юзера ноют "ну что ж они все своё пилят в разные стороны? договорились бы - вместе уже б что-то было стоящее давно"
>> идейных у нас полно, мамаша. с реализаторами жопа.
> В основной массе за сегодня выслушал лишь одну основную идею:Нет. Выслушали Вы множество ценных идей, например, "тебе надо -- ты и делай". А вот что пожелали услышать -- вполне согласуется с остальным возвышенным мечтательством явно не читавшего тот же just for fun о том, как порой рождаются прикладные ядра.
Впрочем, и впрямь март на носу. Только это повод на витамины налегать и прогулки, а не форумы :o)
> Нет. Выслушали Вы множество ценных идей, например, "тебе надо -- ты
> и делай".Снова же: советы "что делать".
Но я не спрашивал об этом советов.Кроме того, если только меня касаются все эти линуховые уязвимости - то кто-то из нас неправ.
> А вот что пожелали услышать -- вполне согласуется с остальным возвышенным мечтательствомВы психологом не подрабатываете?
Доктор, проходите.> явно не читавшего тот же just for fun
Ванга из Вас не очень.
Лет 10 назад прочитал.
> о том, как порой рождаются прикладные ядра.Ну да, сначала пишется какой-то код, а лишь потом приходят идеи?
> Кроме того, если только меня касаются все эти линуховые уязвимости -
> то кто-то из нас неправ.Тёплое с мягким.
>> вполне согласуется с остальным возвышенным мечтательством
> Вы психологом не подрабатываете?Не-а, но приходится порой и психологов из депрессии вытаскивать (кстати, тяжелее, чем просто людей)...
>> явно не читавшего тот же just for fun
> Ванга из Вас не очень. Лет 10 назад прочитал.Рад ошибиться, но главное оттуда Вы так, похоже, и не поняли: "сделай сам".
>> о том, как порой рождаются прикладные ядра.
> Ну да, сначала пишется какой-то код, а лишь потом приходят идеи?Нередко именно так. В случае линукса, выросшего из терминалки -- в очень большой мере.
>> Кроме того, если только меня касаются все эти линуховые уязвимости -
>> то кто-то из нас неправ.
> Тёплое с мягким.Т.е. общие для многих проблемы - это некие абстрактные проблемы, которые один человек не имеет права подымать/обсуждать?
(впрочем, вопрос литоричекий, можно игнорить)
> Не-а, но приходится порой и психологов из депрессии вытаскивать (кстати, тяжелее, чем
> просто людей)...Верю %) У них такие калейдоскопы в плане работы психики
> Нередко именно так. В случае линукса, выросшего из терминалки -- в
> очень большой мере.Звучит красиво и романтично.
Но я всё-же склонен считать, что сначала думает голова, потом даёт команду рукам и те - согласно придуманного головой - что-то пишут на клаве.
Если последовательность какая-то другая - то.... это уже ближе к тем самым психологам в депрессии :)
Михаил, он в этом случае прав, а Вы -- нет
целеполагание давно уже обозначено самой архитектурой микроядра
а с грамотными системщиками и правда -- швах, никто не знает как надо, но все только ноют и кукарекают как не надо
нигилизм и деградация очень рядом находятся...
> целеполагание давно уже обозначено самой архитектурой микроядра
> а с грамотными системщиками и правда -- швах,
>все только ноют и кукарекают как не надоРекурсивно поделил на "", молодец. Засчитываю не-присоединение ко "всем".
> нигилизм и деградация очень рядом находятся...
>[оверквотинг удален]
> Ну собственно вот, опять...
> Указыателей ЧТО ДЕЛАТЬ - тоже много. А вот обсудить без эмоций КАК
> ДОЛЖНО БЫТЬ в итоге - этого встретил пока мало...
> Все резво рвутся (а равно указывают другим) сразу что-то писать. Что -
> неважно, главное писать. Немедленно. Иначе и обсуждать мало кто хочет.
> А ничего, что перед тем как писать, лучше подумать и обсудить?
> Потому как без обсуждения - то и получается, что каждый держит какой-то
> заброшенный гитхаб репу с оертаниями какого-то поделия, а юзера ноют "ну
> что ж они все своё пилят в разные стороны? договорились бы
> - вместе уже б что-то было стоящее давно""Иногда, глядя с крыльца на двор и на пруд, говорил он о том, как бы хорошо было, если бы вдруг от дома провести подземный ход или чрез пруд выстроить каменный мост, на котором бы были по обеим сторонам лавки, и чтобы в них сидели купцы и продавали разные мелкие товары, нужные для крестьян..."
> "Иногда, глядя с крыльца на двор и на пруд, говорил он о
> том, как бы хорошо было, если бы вдруг от дома провести
> подземный ход или чрез пруд выстроить каменный мост, на котором бы
> были по обеим сторонам лавки, и чтобы в них сидели купцы
> и продавали разные мелкие товары, нужные для крестьян..."И только неспособность людей договариваться мешает им реализовать общие цели (мост с купцами - вряд ли состоит в общих целях крестьян)
два тома "Мертвых душ" этому господину.
> два тома "Мертвых душ" этому господину.Второй - лучше в электронном виде
... и трёхтомником Кнута по кумполу.
Только что в openSUSE прилетело 4.10. Ну думаю, вот радость то - сейчас посмотрю что за зверь этот Virtual GPU. Ага, щазз. Система загружается до консоли и начинает мерцать между экраном загрузки и tty 3-4 раза в секунду, что даже залогиниться невозможно.
Думаю, как раз это-самое и словил.
Кто из адвокатов микроядерности ("все на микроядра!") поработал под/с микроядрами --- поднимите руки.
те у кого iphone :)
> те у кого iphone :)Да. Там же XNU, Mach &etc. Вот кто всех передее. Впрочем, всегда и был передее.
> те у кого iphone :)Кстати, кстати. Действительно.
> Кто из адвокатов микроядерности ("все на микроядра!") поработал под/с микроядрами --- поднимите
> руки.(внезапно) DragonFlyBSD - гибрид
Лес рук!
> Кто из адвокатов микроядерности ("все на микроядра!") поработал под/с микроядрами --- поднимитеЯ работал с QNX. Приятная система. Всё динамически загружается/выгружается. Мышь подтормаживает, но вся система работает как часы. До сих пор поражаюсь, как можно было пускать столько усилий на линуксы при наличии готовой системы.
> До сих пор поражаюсьПоражайтесь где-нибудь ещё, ладно? Здесь плоды Вашего обострения не нужны, см. правила.
PS: "работал" -- это как то "посмотрел", которое честные люди в резюму не пишут, да?
> Я работал с QNX. Приятная система. Всё динамически загружается/выгружается. Мышь подтормаживает,
> но вся система работает как часы. До сих пор поражаюсь, как
> можно было пускать столько усилий на линуксы при наличии готовой системы.Это прекрасно и чудесно, что оно работает.
Но в долгосрочной перспективе от закрытых продуктов можно взять лишь идею и доказательство принципиальной реализуемости.
> Я работал с QNX.Пи^WБалабол.
напомните, это не тот airlied который в конце прошлого года обложил перстом животворящим амдшных девелоперов за монолитный патч к amdgpu?ну правильно, он же @redhat.com, ылита, ему можно.
> напомните, это не тот airlied который в конце прошлого года обложил перстом
> животворящим амдшных девелоперов за монолитный патч к amdgpu?Тогда - он обложил, всё правильно, он как Линус!
Сейчас - Линус его обложил.Замечаешь разницу?
> ну правильно, он же @redhat.com, ылита, ему можно.
Вообще гря, есть мнение, что нужно. Но есть нюансы. :(
Чудеса
В DragonFly BSD делают гибридное ядро.
Сделали возможность переноса дров в юзер-левел, очередь сообщений может быть как асинхронной (классические представления), так и синхронной (по ситуации) и потихоньку переносят дрова из ядра.en. wikipedia. org/wiki/DragonFly_BSD#Kernel
Вот и в Линухе нужно сделать так же: добавить микроядерное API, и потихоньку начать выносить стрёмный код к юзерам. Более стабильное и скоростное - может пока побыть и в ядре.
> В DragonFly BSD делают гибридное ядро.
> Сделали возможность переноса дров в юзер-
> Вот и в Линухе нужно сделать так же: добавить микроядерное API, иСим нарекаю xen гибридным линуксом. Аминь.
Все это уже обсуждали тысячу раз. И микроядерный дизайн, и переписывание с Сишки на типобезопасный язык. Слишком много работы, а локомотив несется на всех порах (куча компаний добавляют разные прогрессивные вещи в ядро), за ним в таком случае не угнаться. Так что не надо нам этой лирики
а то, что локомотив может быть несется прямым ходом в пропасть Вас не волнует?
отговорки чисто как у всяких бюрократов выходят: "врач сказал в морг, значит в морг..."
(с Вашего позволения, Михаил)> Уверяю, эту систему уже ничто не спасёт! (кроме полного переписывания)
> Ну вынесешь ты что-то наружу кольца 0 - что дальше? Оно перестанет падать? Или
> ему больше не нужны ядерные API?
> Микроядерность - она строится С НУЛЯ и должна быть корнем системы. Вокруг неё
> строятся все остальные сервисы. Если это сразу не проектировать, потом это
> будет прикручиванием турбины к лошади.Есть принцип, когда после каждого коммита система остаётся работоспособной.
Вот такими небольшими шагами вполне возможно добавить API и затем так же, атомарно переносить по драйверу из 0-го кольца.
Да, "лошадь" может превращаться в "турбину" плавно, оставаясь работоспособной.
Даже если "с нуля" она была пони.
> Есть принцип, когда после каждого коммита система остаётся работоспособной.Уточни, какая из миллиарда систем с ядром Linux будет этой "нулевой точной"?
> Уточни, какая из миллиарда систем с ядром Linux будет этой "нулевой точной"?Дистр чтоли?
Побойтесь Торальдса с РМСом!
##>>> когда после каждого коммита
##>>> система остаётся работоспособной.
>> Уточни, какая из миллиарда систем
>Дистр чтоли?Не-а, железка. Точнее комбинация железок... Чуть поиграл словами, 'система': ОС <=> хост. "система остаётся работоспособной" => "ОC/ядро остаётся работоспособным на всех [тех же] железках"
Чувствуешь накат комбинаторики? "когда после каждого коммита" ""просто""ТМ перепроверяем на всех железках, да.
//Ко всем балаболам за "тестирование решает" относится.
> DRM-подсистеме ядра LinuxСначала грешным делом подумал, что проприерасты пролоббировали внедрение Digital Rights Management в ядро. Чур меня, чур (((
L4/L4se - Это ядра.А то что у моноядер - это болото ненадежности.
> L4/L4se - Это ядра.
> А то что у моноядер - это болото ненадежности."Валера-а-а-аА! Ты д**а-а-а-а-А*??!"
Не сходя с места объясни, как твой влажный в**** отностися к теме.