LINUX.ORG.RU

Ядро на ФП


0

2

В соседнем треде обсуждается возможность переписывания ядра на ООП. Но ядро и так уже написано в ООП стиле. Меня заинтересовала идея написания ядра с использованием функциональной парадигмы во все поля (не обязательно на функциональном языке). Из профитов видится большая надежность, читаемость, вероятно и более простое сопровождение, из минусов меньшая скорость. Хотелось бы услышать Ваше мнение на эту тему. Кто дополнит/исправит?

★★

Последнее исправление: Vernat (всего исправлений: 1)

Ответ на: комментарий от Vernat

подробнее можно?

Ты не знаешь известный house?! Даже загуглить не можешь? Все знают house!

anonymous
()

Машина Тьюринга vs Лямбда исчисление. Только с тем нюансом, что компьютер создан для операций Тьюринга (грубо говоря, но вы поняли)

vertexua ★★★★★
()

Linux и так с использованием функций

ms-dos128
()
Ответ на: комментарий от Vernat

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

jamy
()

Из профитов видится большая надежность, читаемость, вероятно и более простое сопровождение

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

А вот главной проблемы ядра - сложности выявления связей между модулями и подсистемами - ни ООП, ни функциональщина никак вообще не решают.

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

Ну нет, мыслите шире! Любой IO - это аргумент/результат функции, это еще не так страшно. Обычные монады io умеют

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

Да что толку «мыслить шире»? При IO изменится поведение любых других кусков кода, использующих IO, число связей вырастает неимоверно.

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

Отличная оптимизация возможна. Но увы ее сейчас банально нет. Стоит запихнуть монаду и она скорее всего реально для строчки в строчку будет создавать объекты и что-то заворачивать. Сделай это в цикле (ой, рекурсии) в низкоуровневом драйвере и всякие монолитные линупсы тебя уделают. Даже микроядра провалились, а там уровень абстракции не такой был, как перейти в функциональную парадигму и иммутабельность.

Даже функциональный массив обычно аммортизированный O(1), о чем дальше говорить. Пока не научится превращать запись в массив в одну-две инструкции говорить не о чем

vertexua ★★★★★
()

Из профитов видится большая надежность, читаемость, вероятно и более простое сопровождение.

Ждем аргументации.

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

Если нет ФП головного мозга и ты просто юзаешь хорошие структуры данных, используешь функции высшего порядка, например над коллекциями, то все ок. Ну а если всякие Arrows и прочую мутотень, которая в примере в учебнике делает код короче после хорошей затяжки, то думаю будет нечитаемая ерунда.

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

Osker и L4se - они как раз на Хаскеле, так что не 3.14ть

Если ты о seL4, то на Хаскеле там спецификация, а не само ядро: The Haskell artifact was used as a basis for manually developing a high-performance C programming language implementation of seL4.

Так что... не 3.14зди.

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

Ждем аргументации.

скорее всего не дождемся

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

Хаскеле там спецификация, а не само ядро

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

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

Из них создаются исходники на С

Ты хочешь сказать, что слова «manually developing» во фразе «manually developing a high-performance C programming language implementation» - это вранье?

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

Оооо, всем два раза «ку» :D

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

емнип L4Ka валидировали на хаскеле

Давно уже!

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

Да это провал. Скажете что мол ядро отличное, просто маркетоиды не прорекламировали, потому его нет в моем телефоне? Да ну, оно точно бы тормозило по сравнению с богомерзким линуксом на говноС.

С и С++ - моветон прикладных систем, но в системный реально лезть не надо, иначе только теоретически будем дуть щеки что оно умеет запускаться

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

Я знаю. И что? Костылить нагенереный код патчами - ужос. Потом компилятор начнет генерить другой код. Надо руками еще патчи на ассемблер накладывать

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

Скажете что мол ядро отличное, просто маркетоиды не прорекламировали, потому его нет в моем телефоне?

Да как знать... OKL говорят, что их микроядро в миллиарде телефонов.

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

Разве не декларируется евангелистами фп более короткий код по сравнению с императивным (меньше кода - меньше ошибок), а так декларативный стиль более простое восприятие?

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

Да как знать... OKL говорят, что их микроядро в миллиарде телефонов.

оно емнип там как гипервизор для остальных поделок

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

Разве не декларируется евангелистами фп более короткий код по сравнению с императивным (меньше кода - меньше ошибок), а так декларативный стиль более простое восприятие?

дело не в коротко/длинно ФП дает чистоту т.е. отсутствие побочных эффектов

exception13 ★★★★★
()
Последнее исправление: exception13 (всего исправлений: 1)
Ответ на: комментарий от exception13

Вы озвучили то, чего я не смог (снимаю шляпу)

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

OKL говорят, что их микроядро в миллиарде телефонов.

оно емнип там как гипервизор для остальных поделок

Это понятно, но что за «остальные поделки»?

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

оно емнип там как гипервизор для остальных поделок

А! Понятно! Значит тогда они ничего не умеют. Подумаешь там гипервизор, вот если б ядро...

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

дело не в коротко/длинно ФП дает чистоту т.е. отсутствие побочных эффектов

Если придираться к словам, то дает не отсутствие, а дает контроль над побочными эффектами. Та же монада IO вполне позволяет создавать побочные эффекты, но они применяются не сразу, а опосредованно (через значение main). Вот, в чем фишка. Правда, осталось мне непонятным, а стоит ли овчинка выделки, чтобы так извращаться над здравым смыслом?

dave ★★★★★
()

И так уже работает без вашего ФеПе

Zorn
()

Можно...

Как раз занимаюсь такой темой около полугода, в промежутки свободного времени, именно на Haskell.

Конечно, желательно в первую очередь почитать репорты по House и Hobbit (dsl для работы с памятью), для того чтобы оценить сложность.

Даже если такую систему будет писать 20 гениев от ФП, то на текущем железе выхлопа оно не даст. Если использовать специальное железо(имею ввиду процессор в первую очередь), типа Reducedron, и под него пилить систему толк будет. Где разрыв между математическими понятиями и железной реализацией будет намного меньше. Вопрос скорости отпадет.

Размер кода, здесь не решаемый фактор. Если действительно написать такое ядро на хаскеле, то система строгой типизации обеспечит еще до запуска работоспособность ядра, т.к сопоставление типов будет вести к наглядной видимости зависимостей системы. Что может, но не факт снять с головы разработчиков много работ по дальнейшему сопровождению и организации API который работает как надо (по сути даже несколько разных API складывающихся как пазл, стыковка только по строго определенным правилам)

Однако, тут встает «головная боль» всего маркетинга в Ит комьюнити: «это ж сколько всякого софта переписать нужно».

P.S: В итоге, пока пытаюсь написать на Haskell микроядро типа смеси ChibiOS и L4 для запуска на ARM платформах, особо далеко управления процессами не зашел, и если расслаблюсь так и сгинет =)

Sigrlami
()
Ответ на: Можно... от Sigrlami

Конечно, желательно в первую очередь почитать репорты по House и Hobbit

А как ты пишешь, если не читал их? Можешь вкратце описать структуру твоего ядра и как оно работает? Каким компилятором пользуешься?

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

если учесть что RTOS частенько one process - multiple threads то использование гипервизора для запуска нескольких инстансов может быть и оправдано. ну и как обычно упоминается Legacy Code Reuse.

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

А как ты пишешь, если не читал их?

Я их читал, я написал автору, что ему желательно почитать.

Каким компилятором пользуешься?

Сейчас я использую jhc, GHC обещали кросскомпиляцию через несколько релизов, возможно перейду на него.

Можешь вкратце описать структуру твоего ядра и как оно работает?

Как обычное «недоядро» (exokernel) есть общий поток исполнения, модуль управление памятью через hobbit и таймеры для работы с железом.

Все ресурсы конечно же видимы, что полная ерунда, ну пока можно, все это висит в памяти, работу с диском, сетями и всей остальной переферией я еще не осилил.

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

OKL бегло упоминает Linux, WindowsMobile, SymbianOS, RTOSes (VxWorks, Nucleus, etc.)

Кхм. Понятно, что всё это можно запустить поверх гипервизора. Но где, в каких мобилах используется более чем одна ОС? А если ОС одна, в чем пойнт гипервизора?

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

Корпоративный сектор. На работе в гипервизоре Android, вышел из офиса WindowsMobile =), или та же ось но там уже другое окружение. Для организаций с высоким уровнем защиты, в целях экономии на телефонах.

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

Корпоративный сектор. На работе в гипервизоре Android, вышел из офиса WindowsMobile =)

Смешно.

Для организаций с высоким уровнем защиты, в целях экономии на телефонах.

Ты считаешь, что этим организациям нужен миллиард телефонов?

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

Ты считаешь, что этим организациям нужен миллиард телефонов?

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

Кстати, вот в РФ недавно военные предложили Android без зонда, а знали б про вот L4 думаю выгоднее бы использовали деньги, но это уже другой вопрос.

Вторая точка приложения, это военные субподрядчики. Это у нас всё в секретных КБ делают. А у них тысячи компаний, где нужно защищаться от промышленного шпионажа еще больше.

Учитывая наличие OKL года так с 2008, вполне могли накрутить 1 миллиард устройств, по всему миру. Может они как Google считают, где китайфон проработавший 4 месяца это активация.

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

OKL об этом деле в подробностях...http://www.ssrg.nicta.com.au/publications/papers/Heiser_08.abstract

О чем «этом»? Там теоретизирования по поводу возможных применений. В имеющемся миллиарде устройств - для чего используется L4? Для «heterogeneous operating-system environments»? Не знаю примеров устройств с 2 и более ОС. Для «manycore chips»? Они стали массовыми уже _после_ того, как было объявлено о миллиарде. «Security»? Запуск полной ОС в гипервизоре не увеличивает уровень безопасности, потому что ее внутренние потоки данных вне контроля гипервизора.

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

Ты считаешь, что этим организациям нужен миллиард телефонов?

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

Ыыы... суммарное _население_ США и Канады гораздо меньше миллиарда.

Учитывая наличие OKL года так с 2008, вполне могли накрутить 1 миллиард устройств, по всему миру

Это не просто «устройство», это «handset». То есть из проданных с 2006 по 2008 год мобильников, 1 миллиард - с L4. Где и для чего она там?

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