Комментарии 31
честно говоря поражаюсь увлеченности людей, которые взялись писать свою ОС, да еще на ассемблере.
Честно говоря, мне это напоминает гонку за лидером.
Что бы ты не сделал, все равно остаешься позади и немного опоздал.
Например, пишешь драйвер USB. Пока разобрался с USB2 — опять начинай сначала, т.к. появился USB3.
Тот же FASM — как иснтрумент. Ограничивает ОС в интеловских процессорах.
Далеко не факт, что они еще долго будут в лидерах.
Может стоит подумать как транслировать ОС в ARM системы?
Например, можно попытаться транслировать на уровне ассемблерных текстов вроде mov eax,[ebx] => ldr r0,[r1] Тогда, наверное, многое из кода можно будет сохранить для портированных версий системы…
Честно говоря, мне это напоминает гонку за лидером.
Что бы ты не сделал, все равно остаешься позади и немного опоздал.
Например, пишешь драйвер USB. Пока разобрался с USB2 — опять начинай сначала, т.к. появился USB3.
Тот же FASM — как иснтрумент. Ограничивает ОС в интеловских процессорах.
Далеко не факт, что они еще долго будут в лидерах.
Может стоит подумать как транслировать ОС в ARM системы?
Например, можно попытаться транслировать на уровне ассемблерных текстов вроде mov eax,[ebx] => ldr r0,[r1] Тогда, наверное, многое из кода можно будет сохранить для портированных версий системы…
Назовите аналог VBE для «ARM систем».
а зачем?
отсутствие VBE на «ARM системах» никак не говорит о том, что это «отсталые системы».
Если посмотреть применительно к Linux, то в исходниках ядра есть папка arch а в ней есть другие папки типа arm или openrisc или x86.
Дальше, в папке arm есть под-папки для специфичных архитектур типа mach-spear6xx или mach-s5pc100.
Таким образом, единое ядро может быть сконфигурировано под разные процессоры и архитектуры.
Да, это труднее в поддержке, но потенциал у многоплатформенного решения шире.
отсутствие VBE на «ARM системах» никак не говорит о том, что это «отсталые системы».
Если посмотреть применительно к Linux, то в исходниках ядра есть папка arch а в ней есть другие папки типа arm или openrisc или x86.
Дальше, в папке arm есть под-папки для специфичных архитектур типа mach-spear6xx или mach-s5pc100.
Таким образом, единое ядро может быть сконфигурировано под разные процессоры и архитектуры.
Да, это труднее в поддержке, но потенциал у многоплатформенного решения шире.
а зачем?Чтобы «транслировать ОС в ARM системы» — KolibriOS использует VBE. Чтобы можно было обойтись без отдельного драйвера для каждой видеокарты.
отсутствие VBE на «ARM системах» никак не говорит о том, что это «отсталые системы».Никто не говорил об отсталости. Проблема в том, что нет единого понятия «ARM системы», есть огромный зоопарк. В отличие от PC, которые неплохо стандартизированы.
Если посмотреть применительно к Linux, то в исходниках ядра есть папка arch а в ней есть другие папки типа arm или openrisc или x86.
Дальше, в папке arm есть под-папки для специфичных архитектур типа mach-spear6xx или mach-s5pc100.
Таким образом, единое ядро может быть сконфигурировано под разные процессоры и архитектуры.
Да, это труднее в поддержке, но потенциал у многоплатформенного решения шире.
Нет, нельзя просто взять ядро и сконфигурировать под новую платформу. Все архитектурно-зависимые части должен кто-то написать, кто-то протестировать, они не возьмутся из ниоткуда. У Linux есть большое количество разработчиков, Linux может себе это позволить. Мы — нет.
Посчитайте, что ли, число подпапок в arch/arm и сравните с той же arch/x86. Зоопарк.
Поддерживаю. Сегодня собирал ядро Linux для рабочего контроллера; мало того, что в testing-ветке debian доступно 56 (56!) архитектур ARM, на каждую архитектуру неплохо бы иметь свою версию gcc (ну ладно, ладно, вариантов поменьше — но всё равно много), не говоря уже про огромный зоопарк периферийных устройств, которые тоже неплохо было бы поддерживать. В итоге пришлось пересобирать ядро 7 раз (используя .config-файл, поставляемый производителем, между прочим, и подпиливая через menuconfig по необходимости), и всё равно не всё гладко — банально светодиод PWR на плате не светится, например.
И всё это на i3 собирается овер 30 минут.
И всё это на i3 собирается овер 30 минут.
НЛО прилетело и опубликовало эту надпись здесь
Вообще собиралось только на одном ядре, а «куча ненужного» из периферии таки будет использоваться с большой вероятностью.
НЛО прилетело и опубликовало эту надпись здесь
Компилировал make без дополнительных опций; make -j3 неплохо ускорил сборку ядра. Не могу назвать использование опций по умолчанию «искусственными ограничениями». Или это все же теперь называется так? Ладно, не будем о моей некомпетентности :)
Вообще, прогресс радует (хотя я всё еще не могу позволить себе хотя бы i3 в качестве домашней машины; да-да, я нищеброд).
Вообще, прогресс радует (хотя я всё еще не могу позволить себе хотя бы i3 в качестве домашней машины; да-да, я нищеброд).
Еще я не очень понимаю, почему был выбран ассемблер как язык программирования для ОС.
Уважать этот выбор я могу, а понять — нет.
Выиграть в быстродействии у современных компиляторов с С/C++ довольно трудно.
Тем не менее, выбор сделан, кода и алгоритмов в колибри ос написано на ассемблере уже очень много.
Как сохранить и преумножить это богатство?
Я могу представить себе некий транслятор с ассемблера intel в ассемблер для ARM.
Я когда-то писал нечто похожее с интел в 3rd-party CPU для FPGA.
Мне тогда потребовалось срочно реализовать алгоритм SHA для специфичного процессора для которого существовал только компилятор ассемблера. Посмотрев на описание SHA я понял, что быстро и правильно я это на ассемблере не напишу. Поэтому был придуман ход конем. Откомпилировали сишный SHA алгоритм в листинг ассемблера x86. Потом написали программу конвертации ассемблерного текста в другой ассемблерный текст для другого процессора. И это получилось и работало.
Я думаю похожий метод мог бы сработать и для колибри. В конце концов, почему бы не помечтать, что ваша ОС может быть установлена на какой нибудь iPhone.
Уважать этот выбор я могу, а понять — нет.
Выиграть в быстродействии у современных компиляторов с С/C++ довольно трудно.
Тем не менее, выбор сделан, кода и алгоритмов в колибри ос написано на ассемблере уже очень много.
Как сохранить и преумножить это богатство?
Я могу представить себе некий транслятор с ассемблера intel в ассемблер для ARM.
Я когда-то писал нечто похожее с интел в 3rd-party CPU для FPGA.
Мне тогда потребовалось срочно реализовать алгоритм SHA для специфичного процессора для которого существовал только компилятор ассемблера. Посмотрев на описание SHA я понял, что быстро и правильно я это на ассемблере не напишу. Поэтому был придуман ход конем. Откомпилировали сишный SHA алгоритм в листинг ассемблера x86. Потом написали программу конвертации ассемблерного текста в другой ассемблерный текст для другого процессора. И это получилось и работало.
Я думаю похожий метод мог бы сработать и для колибри. В конце концов, почему бы не помечтать, что ваша ОС может быть установлена на какой нибудь iPhone.
Еще я не очень понимаю, почему был выбран ассемблер как язык программирования для ОС.В быстродействии — трудно. В размере кода — тривиально.
Уважать этот выбор я могу, а понять — нет.
Выиграть в быстродействии у современных компиляторов с С/C++ довольно трудно.
Я могу представить себе некий транслятор с ассемблера intel в ассемблер для ARM.Теперь понятно, вы просто представляете себе неправильный образ. Для кода, который принимает на вход блок данных и даёт на выход преобразованный блок данных — да, в принципе это возможно. Но операционная система — это не код, который как-то преобразует заданные данные.
Я когда-то писал нечто похожее с интел в 3rd-party CPU для FPGA.
Мне тогда потребовалось срочно реализовать алгоритм SHA для специфичного процессора для которого существовал только компилятор ассемблера
Операционная система управляет ресурсами компьютера. Ресурсы PC в значительной степени одинаковы на разных машинах — по крайней мере, достаточно, чтобы одна и та же дискета или флешка могла загружаться и выводить картинку на всех PC. Зоопарк ARM — другой, там даже загрузиться-то переносимо нельзя, не говоря уже о выводе картинки.
Я ни в коей мере не умаляю Ваших заслуг.
Наоборот весьма восхищен Вашим трудолюбием и упорством.
На мой взгляд проблема состоит в том, что
1) компьютеры как PC в последнее время сильно сдают позиции. Да, они остаются на рабочих местах инженеров и дизайнеров. Их ПО — это SolidWorks, AutoCAD, PhotoSHop, Corel и так далее. Это специализированное ПО требующее ресурсов и много места для большого монитора. Тем не менее, продажи ПК падают. Еще как-то продаются ноутбуки — да, считаем их PC совместимыми, но как долго это будет продолжаться не известно.
2) Вы говорите о том, как тривиально выиграть в размере кода, когда пишешь на ассемблере. Но, сколько стоит этот выигрыш? Стоимость носителей, шлеш и ddr памяти будет снижаться. А стоимость ассемблерной разработки — врядли. Я знаю, по своему опыту, что такое писать программу на ассемблере. Я несколько лет сопровождал одну программу для специфичного процессора в FPGA. Там был реализован и TCP стек и графическая библиотека и USB и крипто и всякое-якое. Смена процессора на target device выбросилв всю многолетнюю работу на свалку истории. Жалко.
Не желаю Вам этого пережить.
Наоборот весьма восхищен Вашим трудолюбием и упорством.
На мой взгляд проблема состоит в том, что
1) компьютеры как PC в последнее время сильно сдают позиции. Да, они остаются на рабочих местах инженеров и дизайнеров. Их ПО — это SolidWorks, AutoCAD, PhotoSHop, Corel и так далее. Это специализированное ПО требующее ресурсов и много места для большого монитора. Тем не менее, продажи ПК падают. Еще как-то продаются ноутбуки — да, считаем их PC совместимыми, но как долго это будет продолжаться не известно.
2) Вы говорите о том, как тривиально выиграть в размере кода, когда пишешь на ассемблере. Но, сколько стоит этот выигрыш? Стоимость носителей, шлеш и ddr памяти будет снижаться. А стоимость ассемблерной разработки — врядли. Я знаю, по своему опыту, что такое писать программу на ассемблере. Я несколько лет сопровождал одну программу для специфичного процессора в FPGA. Там был реализован и TCP стек и графическая библиотека и USB и крипто и всякое-якое. Смена процессора на target device выбросилв всю многолетнюю работу на свалку истории. Жалко.
Не желаю Вам этого пережить.
Вам пытаются объяснить 2 вещи:
1) Портирование KolibriOS на ARM будет означать практически полное переписывание с нуля. У нас нет для этого ни времени, ни ресурсов (разработчиков, тестеров), ни желания. К тому времени, как это будет сделано, вместо ARM появится что-то ещё, и Вы опять будете недовольны.
2) Даже если бросить всё и переписать KolibriOS на ARM, она будет работать только на отдельно взятом устройстве (группе устройств). Сейчас на PC она работает (должна работать) на всех компьютерах, использующих процессор x86 Pentium-класса (или совместимые с ним), и выше.
Кроме того, архитектура x86 вовсе не собирается умирать, а наоборот, в последнее время появляются компьютеры на x86 размером и стоимостью как Raspberry Pi, что делает портирование не только невозможным, но также и бесполезным.
1) Портирование KolibriOS на ARM будет означать практически полное переписывание с нуля. У нас нет для этого ни времени, ни ресурсов (разработчиков, тестеров), ни желания. К тому времени, как это будет сделано, вместо ARM появится что-то ещё, и Вы опять будете недовольны.
2) Даже если бросить всё и переписать KolibriOS на ARM, она будет работать только на отдельно взятом устройстве (группе устройств). Сейчас на PC она работает (должна работать) на всех компьютерах, использующих процессор x86 Pentium-класса (или совместимые с ним), и выше.
Кроме того, архитектура x86 вовсе не собирается умирать, а наоборот, в последнее время появляются компьютеры на x86 размером и стоимостью как Raspberry Pi, что делает портирование не только невозможным, но также и бесполезным.
Добавил в избранное. Я буду показывать это своим детям. И вообще всем, кто спросит, почему нельзя Колибри перенести на ARM.
В любой ОС всегда есть код, который может быть общим для разных платформ.
Например, в том же Linux папки kernel, lib, fs, net и другие содержат, в основном, общий для разных платформ код.
Например, как я думаю, VBE нужно, чтобы включить нужный видеорежим. Дальше получив физический адрес framebuffer можно сделать что-то типа mmap в дисплейный драйвер. Собственно дисплейный драйвер далее может быть общим для разных платформ, т.к. пишет-читает из области памяти фреймбуффера и это делается одинаково в интел системах и в арм системах. Таким образом, вероятно функции типа «найти видеоадаптер», «включить видеорежим» и подобные получаются специфическими для платформы. А функции дисплейного драйвера типа нарисовать линию, вывести текст, закрасить область и прочие — получаются едиными для всех платформ.
Платформо-зависимого кода в ядре линукс действительно много — это то, что Вы называете зоопарк. Но я не говорил, что непременно нужно и в колибри портировать сразу в 100 вариантов.
Имхо — нужна всего навсего плюс еще одна платформа (любая), например, чтобы показать возможным инвесторам привлекательность системы и потенциал развития в разных направлениях. Или другой вариант — Вы предлагаете метод портирования (что-то вроде www.linux-arm.org/pub/LinuxKernel/WebHome/aleph-porting.pdf) — и разработчики, кому нужно сами подтягиваются и дописывают платформо-зависимый код.
Прошу не рассматривать мои комментарии как занудство и нравоучительство.
Это всего лишь мысли вслух.
Например, в том же Linux папки kernel, lib, fs, net и другие содержат, в основном, общий для разных платформ код.
Например, как я думаю, VBE нужно, чтобы включить нужный видеорежим. Дальше получив физический адрес framebuffer можно сделать что-то типа mmap в дисплейный драйвер. Собственно дисплейный драйвер далее может быть общим для разных платформ, т.к. пишет-читает из области памяти фреймбуффера и это делается одинаково в интел системах и в арм системах. Таким образом, вероятно функции типа «найти видеоадаптер», «включить видеорежим» и подобные получаются специфическими для платформы. А функции дисплейного драйвера типа нарисовать линию, вывести текст, закрасить область и прочие — получаются едиными для всех платформ.
Платформо-зависимого кода в ядре линукс действительно много — это то, что Вы называете зоопарк. Но я не говорил, что непременно нужно и в колибри портировать сразу в 100 вариантов.
Имхо — нужна всего навсего плюс еще одна платформа (любая), например, чтобы показать возможным инвесторам привлекательность системы и потенциал развития в разных направлениях. Или другой вариант — Вы предлагаете метод портирования (что-то вроде www.linux-arm.org/pub/LinuxKernel/WebHome/aleph-porting.pdf) — и разработчики, кому нужно сами подтягиваются и дописывают платформо-зависимый код.
Прошу не рассматривать мои комментарии как занудство и нравоучительство.
Это всего лишь мысли вслух.
No hard feelings, bro! Просто улыбнуло.
Скрытый текст
да, это смешная картинка.
Но, скажите, кто по вашему написал поддержку, например, OpenRISC процессора в Linux?
Неужели сам Линус Торвальдс? Конечно нет…
OpenRISC — это такой процессор для FPGA, его разработчики недавно пытались насобирать денег на первый чип — но не знаю получилось у них или нет. OpenRISC — это такое мизерое явление в IT индустрии, но зато у них есть свой порт Linux. Именно свой — сами написали.
Линукс хорош тем, что хотя бы позволяет надеяться на результат…
Конечно, до счастливого конца дойдут не все, многие уйдут в небытие. Например, как ушли ранние процессоры ARM, те что без поддержки MMU.- сейчас их поддержки в kernel3 уже нет.
Однако, Linux долго будет на плаву by default, потому, что позволяет внешним силам влиять на себя.
Но, скажите, кто по вашему написал поддержку, например, OpenRISC процессора в Linux?
Неужели сам Линус Торвальдс? Конечно нет…
OpenRISC — это такой процессор для FPGA, его разработчики недавно пытались насобирать денег на первый чип — но не знаю получилось у них или нет. OpenRISC — это такое мизерое явление в IT индустрии, но зато у них есть свой порт Linux. Именно свой — сами написали.
Линукс хорош тем, что хотя бы позволяет надеяться на результат…
Конечно, до счастливого конца дойдут не все, многие уйдут в небытие. Например, как ушли ранние процессоры ARM, те что без поддержки MMU.- сейчас их поддержки в kernel3 уже нет.
Однако, Linux долго будет на плаву by default, потому, что позволяет внешним силам влиять на себя.
Я не спорю, что Linux — в общем и целом очень хорошая ОС, и пользуюсь ей на большом количестве устройств с процессорами разных архитектур: x86, x86-64, PowerPC и куче ARM. Но это не отменяет того факта, что Linux — типичный представитель явлений: bloatware, «давайте добавим ещё вот эту фичу» и «каждой бочке затычка». Long live Linux! Админь.~
Напомню, есть несколько операционных систем (тсс! среди не-POSIX таких, кажется, большинство), которые не ставят своей целью работать на каждом холодильнике и каждой микроволновке — о нет; их цель — пользователи строго определенного железа.
Пардон, что-то меня понесло; речь же о другом: вы говорите, что найдутся желающие что-то куда-то переносить, но увы, за последние несколько лет я видел лишь несколько желающих «поруководить», и огромное количество «эх, если бы у вас была %killer_feature%, я бы %do_something%». Хотя, грех жаловаться — «новобранцы» имеются.
Напомню, есть несколько операционных систем (тсс! среди не-POSIX таких, кажется, большинство), которые не ставят своей целью работать на каждом холодильнике и каждой микроволновке — о нет; их цель — пользователи строго определенного железа.
Пардон, что-то меня понесло; речь же о другом: вы говорите, что найдутся желающие что-то куда-то переносить, но увы, за последние несколько лет я видел лишь несколько желающих «поруководить», и огромное количество «эх, если бы у вас была %killer_feature%, я бы %do_something%». Хотя, грех жаловаться — «новобранцы» имеются.
я извиняюсь спросить — колибри ОС — это коммерческая система или нет?
В смысле «новобранцы» получают зарплату или нет?
В смысле «новобранцы» получают зарплату или нет?
Колибри — free-as-in-freedom and free-as-in-beer. Какая зарплата, вы о чем? :)
Когда KSoC проходил — тогда да, «пионеры» получили честно заработанные, а в подавляющем большинстве случаев награда за помощь системе — это опыт, респект и уважуха.
Когда KSoC проходил — тогда да, «пионеры» получили честно заработанные, а в подавляющем большинстве случаев награда за помощь системе — это опыт, респект и уважуха.
Однако, корпоративный блог на хабре стоит небольших, но денег: 15тыс./мес.
Или «новобранцы» еще и скидываются на поддержание имиджа проекта?
Честно, всегда хотелось иметь проект для души, но как? кушать-то хочется…
Или «новобранцы» еще и скидываются на поддержание имиджа проекта?
Честно, всегда хотелось иметь проект для души, но как? кушать-то хочется…
За корпоративный блог нужно сказать «Спасибо» добрым людям. :) Как и за пожертвования на KSoC, и всё остальное :)
Да, соглашусь — времени на хобби из-за работы порой остается очень мало.
Да, соглашусь — времени на хобби из-за работы порой остается очень мало.
Блог на Хабре для таких, как мы, недавно стал бесплатен: habrahabr.ru/company/tm/blog/197634/
Смотрим сюда — пакет «Стартап», цена 0 руб.: habrahabr.ru/info/advertising/corporate/
Прямой линк: habrahabr.ru/info/hello_startup/
За хостинг проекта платит XVilka. На KSoC деньги пожертвовали люди (участники проекта, в том числе). Я лично пожертвовал на проект в общей сложности где-то ± $3,000. У меня была такая возможность, и мне не жалко.
А вот времени на проект из-за работы действительно остаётся очень мало.
Смотрим сюда — пакет «Стартап», цена 0 руб.: habrahabr.ru/info/advertising/corporate/
Прямой линк: habrahabr.ru/info/hello_startup/
За хостинг проекта платит XVilka. На KSoC деньги пожертвовали люди (участники проекта, в том числе). Я лично пожертвовал на проект в общей сложности где-то ± $3,000. У меня была такая возможность, и мне не жалко.
А вот времени на проект из-за работы действительно остаётся очень мало.
Бессмысленно, ARM-процы еще меньше стандартизированы, и то, что работает на одном проце, может не работать на другом. Исправте меня, если я ошибаюсь.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Поддержка USB в KolibriOS: что внутри? Часть 5: уровень логического устройства