> эмуляция это то, чего нет,У RAM нет изначально никаких "блоков", по определению RAM. Так же как x86 на самом деле не умеет выполнять ARMовские программы. Что общего? Это абстракции создаваемые дополнительным софтом.
> а блочное устройство из РАМ сделать можно споскойно, и это не эмуляция.
Изначально блоков нет. Но можно создать абстракцию добавочным софтом.
> какой нафиг бай, а бит я могу адресовать? а почему не могу?
В некоторых штуках, типа Cortex M, можно и лобовую атомарную адресацию конкретных битов 1 операцией. Они забавно сделали: замаппили регионы адресов в отдельные биты. И вот уже запись u32 в конкретный адрес - пишет 1 конкретный бит в регионе alias'а. Можно и чтение, значение бита вернет. Почему u32? Нативный размер слова и шины проца, видимо так проще всего было, а адресов много и экономить не требовалось. Можно, вот, и 1 бит атомарно, если это встроенная RAM или регистры периферии.
> потомучто минимальный блок данных который можно адресовать в РАМ это 8 бит!
Процы могут с этим фактом жить, напрямую адресуя его, в отличие от "блочных устройств". И команды для работы с битами и даже битовыми полями бывают. Впрочем вон пример проца который и 1 бит в своей RAM за 1 операцию шины адресует.
> тоже самое и с хдд, адрессуются блоки данных, а не байты, а прикол знаете в чем?
> а бай вовсе не 8 бит, бывает и 7 и 9 лол кек.
Бывает много всякой странной фигни но я не вижу смысла ее обсуждать в топике про более менее обычные фс. В этом контексте под блочным устройством понимают вполне характерные абстракции.
> адрессуются блоки данных, я не виноват что у хдд блок данных имеет
> размер 512 байт, а рам 1 байт.
Блоки данных с HDD изначально вообще не существуют в адресном процтранстве проца. И поддержанием связанных с этим абстракций так то занимается довольно большой пласт софта. С которым "файлушники" в линухе неизбежно познакомятся.
> смещению относительно какого базавого адреса? вы понимаете что есть базовый адрес и смещение?
Можно 0 для определенности. Хороший базовый адрес, у всех одинаковый более-менее. Даже на жестком диске понятие вида "150423-й байт от начала" как таковая - валидно. А то что выполнять "mod 512 math" прерогатива дополнительного софта - бывают в жизни огорчения. Если уж возвращать вам фавор, mmap() делает весьма убедительную абстракцию линейного адресного пространства из вон того. Однако это не делает HDD RAM как таковым. На уровне его нативного IO он не может в рандомный доступ к 150423-му байту. И придется просить сектор с ним, а там если хотите можете RMW сами сделать. Но это как раз уже и был не рандомный доступ а блочный.
> а что если я не делаю аллокация, моя программа что нибудь знает
> о памяти? нет не знает.
Эй, эксперт, а вы программировать точно умеете и понимаете программную модель типовых компьютерных систем? В неймановской абстракции адреса существуют "сами по себе" и то что там RAM будет например изначально замаплен - ничему не противоречит. Аллокация это абстракция многозадачных ОС (которые сами так то абстракция). Скажем в C можно программировать и совсем без *alloc(). Используя стек, или статическое распределение памяти. Более того - в embedded вполне нормально если *alloc() в фирмвари вообще нет. При этом память не может "закончиться". Такой абстракции просто нет. И если оно запустилось - то уж работает. Исключение разве что переполнение стека.
Более того - у многих современных камней есть блоки SRAM доступные сразу после power up без дополнительных условий, оговорок и конфигурации этого. Вот прям с power up первыми командами берете и адресуете это. В терминах машинного кода на этом этапе аллокаций вообще нет как класса, эта абстракция будет создана где-то сильно потом.
> Моей программе вообще доступна вся память если на то пошло.
Ей доступно "все адресное пространство". Что в нем замаплено в общем то отдельный вопрос. Но ничему не противоречит и что туда та или иная RAM замаплена, сразу, хоть при power up системы, при этом RAM доступен, а абстракции типа "аллокаций" если и будут то где-то сильно потом. И вообще-то они опциональны, даже если с ними и удобнее/лучше в ряде случаев.
> все зависит на каком уровне абстракции работает ваша программа, вот для этого
> и придумали файловые системы,
Как ни странно posix поддерживает абстракцию как будто это обычная 1-задачная система и заметить отличия можно только если это отдельно и явно захотеть и оно зачем-то надо было. Это упрощает програминг: если кто не хочет париться многозадачностью, он и не парится. И код так портабельнее.
> чтобы не думали о всяких смещениях и адрессах.
Работая с файлами таки все равно придется в ряде случаев трекать из смещения. А какие нибудь БД так и половину абстракций ФС пересоздают, а файлом оно в основном "для удобства менеджмента админом". Этому вообще может быть удобнее на RAW разделе - но так админам неудобно, как например стораж расширить? В btrfs то "device add", получаем +n места, файл без проблем отрастет и туда. А с разделом такое упс. Не тот уровень абстракций.
> Достаточно иметь интерфейс, открой такой-то файл, запиши в него столько-то
> байт по такому смещению (учтите смещению относительно начала файла,
Фокус в том что файловые системы так то тоже - абстракции. Как впрочем и файлы. Их поддерживает специфичный софт - файловые системы.
В простейшем случае можно и без этих абстракций. У меня есть несколько фирмварей напрямую таскающих сектора с SD/MMC. Но в операционке общего назначения это было бы не очень удобно. В узкоспециализированной фирмвари где оно для специфичных целей - можно и вот отдельные сектора. И таки RMW секторов и не особо удобно и не то чтобы сильно эффективно vs реально рандомный доступ. И память под буферизацию сектора жрет, для мелочи - аргумент. SD/MMC в этом смысле типичный представитель "блочных устройств". С весьма нерандомным доступом.
> и организует хранение файлов. А все остальное это уже работа драйвера устройства.
Драйвера устройств так то тоже - всего лишь абстракции. При том в разных ОС еще и разные.
> для уровня который предоставляет ФС до лампочки, пользователю нужно, открыть записать и
> закрыть, все.
Обычные ФС могут быть нереализуемы на неподходящей абстракции. И тогда этого не будет. Или будет вам наглухо readonly эмуляция - и хватит с вас. А попробуйте в роутере squashfs перезаписать, узнаете в чем прикол!
Абстракция ФС - есть, но... 1) у нее нет понятия записи и 2) это не "блочное устройство" внезапно а MTD вообще какой окажется. И 3) более обычные ФС на таком жить конечно же не смогут.
> ДЛя ФС прочла блок, записала блок и всё. Драйвер
> как там представляет блочный интерфейс уже не важно.
А таки вот блочные устройства и память с произвольным доступом отличаются на самом базовом уровне, еще до того как все вон те абстракции станут актуальны. И в общепринятом понимании критерий это минимальный юнит IO в основном.
