>(Дальнейшее развитие идеи опущено)
>Насчёт файловых систем замечание отчасти верное, но только по отношению к OpenBSD.
>В NetBSD и FreeBSD всяких специализированных ФС побольше. Ну и какие ФС там сделаны спецом под флеш? Название в студию. Чтоб выравнивание на erase-block (обычно это 64-256Kb, зависит от чипа), размазка записей (wear leveling), учет логических и физических свойств флеша в структурах ФС и прочая. Как это у jffs, ubifs и т.п. специально заточенных ФС сделано. Посмотрите на их устройство и лэйаут и поймете что это не просто "оптимизации под". Это - решения сделанные под конкретные задачи - лэйаут и т.п. сделаны под специфику флеша. На коем обычные ФС - или стушуются или будут работать очень неоптимально и могут достаточно быстро затереть локальные области в флеше до дыр. Просто в силу того что делались с допущением что диски пишутся секторами по 512 байтов. А для флеша, особенно прицепленного напрямую к процу - сие мягко говоря неверно. Там запись 512 байтов как правило трансформируется в read 128Kb to RAM, modify 512 bytes in RAM, erase 128K block, write 128K from RAM. А если таких записей несколько и в одну область, для обычной ФС выйдет медленное и унылое протирание 1 блока несколько раз. И тормозно и срок службы блока (циклы перезаписи) просирается качественно. Штуки типа jffs и зачастую обойдутся без стирания и записи размажут по нескольким блокам.
>Да, покажите мне SOHO-роутер (коли уж мы обычно сбиваемся на эту тему)
Ну, я не виноват что это одно из основных применений пингвинов в embedded, к тому же достаточно близкое к тому что вы описали.
>синтенсивной работой с диском. ;)
Строго говоря - по минимуму надо записывать только конфигурацию, и минимально - производители обходятся squashfs-lzma, например, а конфиг где-то сбоку, как то в отдельном блоке флеша. Squashfs-lzma хорош тем что весьма компактный и прилично сжатый, декомпрессуется на лету по мере надобности, etc. Но - read-only, увы. Только так получается гемор если надо файлы менять, помнить статистику или логи между ребутами, etc. Пакеты вообще фиг поставишь, а чтобы заменить всего 1 файл - придется пересобрать образ и перелить его. Что немного геморройно, если хочется рассмотреть это не как "коробочку которая что-то делает" а как "сетевой компьютер с пингвином на борту" позволяющий более динамичную реконфигурацию и адаптацию под задачи "на ходу". В этом плане мне больше нравится подход openwrt - readonly база в squashfs на которую при помощи mini_fo накладываются изменения хранимые в jffs2. При этом есть и failsafe режим (просто не цепляется jffs2 и система стартует в нулевом виде без юзерских изменений бывших в jffs2, потенциально способных сделать ОС небутабельной) и возможна модификация всей ФС. Граблем данного подхода (ничто не бывает на халяву) является то что обновление системных пакетов которые в squashfs сидят - приведет к тому что они сожрут место 2 раза - базовый вариант из squash не сотрется, а обновленный выжрет место под себя в jffs2. Было бы реально любопытно посмотреть как бздуны изобразят какое-то подобие всей этой механики. Самое интересное - из чего они это сделали бы.
>Оперативная память там, кстати, тоже понадобится и так — на state'ы хотя бы.
Как минимум чтобы процессы и ядро там держать (выполнять код из флеша или вообще невозможно, например из nand или spi прямое выполнение кода обычно невозможно, или медленно, в случае NOR, так что придется процессы и ядро 1 фиг в оперативу перегружать).Ну и всякие там таблицы (особенно connection tracking в случае NAT).
>А вот насчёт специфических загрузчиков, SPI и прочего — это было весьма
>пальцем в небо. :) Ни NetBSD, ни OpenBSD не привыкать к
>подобным вещам.
Ну... после гуглинга разных логов загрузки я накопал пример показывающий что фря в принципе может видеть spi-флешки. Для нетбзди и опенка такое не накопал. Допустим что вам как краеведу виднее, но логи загрузки и т.п. были бы как-то убедительнее. Они у вас есть?
>Или как вы думаете, они работают на отличных от x86 архитектурах?
Если честно, я не видел ни 1 железки с нет или опебсд на не-х86 архитектуре. А они где? Может, у вас хотя-бы логи загрузки с таковых железок найдутся? :)
>Вы ж лучше бы всё-таки проверили, это легко недолго. А так выглядите теперь смешно. :)
Легко? Недолго? Хорошая шутка, мне нравится - это и правда смешно, я оценил. А инструкцию по сборке образа ROM - как, не пришлете, раз уж у вас так просто все? Если хотите - можем даже поиграть с вами в забавную игру: "кошки-мышки, embedded edition". Правила простые: я присылаю вам non-x86 платку (например как вам атерос 71хх?), а у вас все шансы на руках показать - как оно там легко и недолго. Желательно за ~пару недель после получения платки, раз уж "легко недолго". Как пруф с вас рабочий образ который можно залить в такую же железку и/или описание как его создать. В случае успеха (система запускается с платки и делает что-то полезное, как то отдает файлик по HTTP с локальной ФС, роутит, ну или еще что в этом духе) - платка совершенно задаром остается вам на память (как символ уважения к мастеру своего дела). Не говоря уж о том что вы утрете мне нос по полной и срубите немеряное уважения комьюнити *бсд :).Как, не хотите сыграть в такие кошки-мышки? :). Ах да, разумеется, читерить не полагается: загрузка - с самой платы, а не с внешнего TFTP, ну и все-таки только сплюнуть кульные мессаги в уарт за полезную работу не считается (а какая от них польза?). Ну а если не осилите - признаете что погорячились что "легко недолго" и как мстя - ну например, честно оплатите платку .. или отдадите ее кому-нить кто сможет ее поюзать более дельно чем просто артефакт на стену, etc :P.
>И не забывайте, что *BSD — это полноценные ОС, а Linux —
>это только ядро. Вы можете назвать _дистрибутив_ Linux с портабельностью NetBSD? ;)
В embedded применениях - это скорее минус чем плюс. Берется ядро и отдельно обвязка под конкретную задачу. И всякие там dnsmasq и бизибокс - компактнее чем аналогичный набор дискретных утилей с тем же функционалом. Потому что оно не тянет за собой вагон манов, пять страниц вербозного хелпа в коде программы и т.п. утяжеляющие программу сущности и по зависимостям ничего особо не требует. При том компактность зачастую не слишком в ущерб фичности. Ну а посокольку они 1 фиг дергаются в automated режиме, читать маны хелпы 1 хрен некому и невелика потеря :)
>Ну а насчёт загеммораивать жизнь — так это может к чему угодно
>относиться, что легко портируется. А вы пока толком не доказали, что
>*BSD плохо портируется.
Можете доказать что это легко - см выше про игру в кошки-мышки, например :).При том вам это логичнее делать чем мне - кто в *bsd хорошо разбирается? Я вот не вижу для себя как это "легко недолго", но у вас могут быть все шансы показать мне это и доказать что я не прав, если захотите :)
>Наоборот, Linux, именно и только ядром, только сравнительно
>ядром только недавно догнал OpenBSD и NetBSD. Вам ведь ещё и
>приложения какие-то нужны (от управления фаерволом до web-сервера со скриптами), а
>это уже совсем другой разговор.
Ога. И оно такое есть. Например для роутингово-фаервольных мероприятий хоть тот же openwrt например :).В принципе ничто на нем не мешает и вебсервак запустить (в общем то все ограничивается только ресурсами железа). Я даже запускал там lighttpd, кстати.В принципе к нему и php прикрутить можно, я правда пока такими наворотами не заморачивался, мну чуть иные аспекты пока интереснее :-)
