>> Не так. "RAM может, но не обязан, использоваться для эмуляции блочных устройств".
> RAM и есть, а обязан или не обязан - не имеет значения.Это именно эмуляция, дополнительным софтом и абстракциями. Я на x86-64 запускаю виртуалки с системой команд ARM или RISCV. Это не делает x86-64 ARM-ом. Нативный интерфейс x86-64 проца это x86-64 поток команд. Даже если я и могу вот тут запустить ARMовский бинарник, это весьма забавная абстракция, не более. С RAM аналогично, то что я могу вывесить там эмуляцию блочного девайса не делает ее блочным девайсом.
> лол, кек - понятие "произвольный доступ" используется в терминах БЛОКА,
"Блок" и "произвольный доступ" - взаимоисключающие параграфы. Вы или можете адресовать конкретный байт или нет.
> у каждого блока данных свой адрес, к которому можно произвольно обратиться, и не
> важно каков размер этого блока данных, 1 или 4096 байтов.
Вообще-то важно. Вон там машинный код напрямую может пойти и положить число 234 в адрес 0x100 и это немедленно и без дополнительных условий обеспечивается, если там RAM. А в случае с блоком - так нельзя. Как максимум можно подкостылить и сделать вид что получилось, но вот это уже - эмуляция.
> https://en.wikipedia.org/wiki/Hard_disk_drive
Я рад что вы умеете читать вику, теперь запишите число 234 по смещению 0x100 от начала, не портя другие байты. А, так изначально нельзя? Потому и блочное устройство - на уровне его нативного интерфейса. А то что swap им RAM изображает - круто, но считать ЭТО за именно "random access memory" я все же не буду. Потому что хотя чередой RMW + IO и можно изобразить ЭТО, сие будет крайне медленно и неэффективно и не является нативным интерфейсом девайса.
> ну за это спасибо Фон Нейману, добавляем новый диск - новое устройство
> хранения, а добавляем новую планку памяти - доп. размер.
Планка напрямую адресуема из программы - а HDD на уровне кода программы - изначально вообще не существует. Это уже надо запросы к операционке делать (сисколы). А переменную программы там не разложишь. Такая "небольшая" разница на уровне программного интерфейса.
> Хотя между этими устройствами хранения одна лишь разница, одна
> энергозависимая другая - нет.
А также какими юнитами они адресуются. Конкретный байт или адресуем напрямую или нет. К слову старые ARM програмеры искренне ненавидели за загоны насчет выравнивания. Это как раз клещилось с этой абстракцией, и доставляло море неудобств програмерам.
>> А вот обратиться так к HDD и т.п. - удачи.
> https://en.wikipedia.org/wiki/Logical_block_addressing
В этих терминах не описывается "хочу чтобы байт по смещению 0x100 стал равен 234". Чтобы это обеспечить придется сделать нехилую эмуляцию, RMW, сисколы и проч. На этом основании я и отказываюсь считать это RAM - изначально "random access" там как раз и нету.
NB существуют и всякие достаточно забавные промежуточные случаи. Скажем SPI флешка сама по себе не есть "random access memory" - оно в общем случае "девайс на интерфейсе" из которого напрямую вообще выполнять ничего нельзя, надо команды слать. А запись там совсем не рандомная. Но небольшим хардварным довеском доступы в регион памяти начинают транслироваться в SPI-команды прозрачно, хоть и медленно. Вплоть до того что проц при RESET читает допустим память с адреса [0x0] - а железка транслирует это в SPI-команды чтения флехи. Результат достаточно трудноклассифицируем. С одной стороны это нечто типа "ROM" для проца, с другой - оговорок столько что это точно не "RAM" и даже "ROM" только с очень большими оговорками и весьма медленно из-за той трансляции. А нафиг это надо? Так мелким штукам может быть проще грузиться, для проца это прямое выполнение, юзается дешевая малолапая SPI флеха, все обеспечивается простыми железками. Но это "внеклассовая" экзотика. Она не цепляется ни как RAM ни как блочный девайс в том же линухе. Как MTD - еще может быть. Но на это и не получится обычную "блочную" файлуху изобразить, да и "ROM" оно только на начальном этапе, потом код загрузчика буферит это в настоящий RAM потому что так неизмеримо быстрее.
