OETF #1 (перевод)

[ov3rwrite 26]

Данная тема является началом переводов статей OETF официального форума oc.cil.li.

 

Что такое OETF?

Цитата Negi:

Цитата

OETF (Open Engineering Task Force) является чем-то вроде аналога IETF (Internet Engineering Task Force) из реального мира. Это место по сути нужно для того, чтобы обсуждать протоколы и стандарты, определённые для коммуникации между компьютерами OpenComputers.

 

Если мне не изменяет память, Lizzy (админ) говорил что здесь мы можем добавлять новые стандарты, комментировать и расширять существующие, такие дела.

 

OETF #1: Кросс-Архитектурная Загрузка / Cross-Architecture Booting / CAB (черновик)

 

ЭТО ЧЕРНОВИК. Он может измениться перед тем, как стать "официальным". Не стесняйтесь предлагать значительные изменения.

 

Тезисы

 

Данный документ даёт рекомендации по работе с EEPROM и размещению архитектурно-специфичного кода.

 

Мотивация

 

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

 

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

 

Этот стандарт нацелен на решение данной проблемы путём предоставления рекомендаций по работе с EEPROM и процедур по размещению загрузочного кода на файловых и секторных загрузочных носителях. Стандарт ориентирован на простоту реализации на максимально возможном количестве систем.

 

Определения

 

Если не указано иное, все ссылки на текст подразумевают 7-битные ASCII-коды. Поведение при встрече байтов с установленным старшим битом не определено.

 

Ключевые слова необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не следует (SHALL NOT), следует (SHOULD), не нужно/не должен (SHOULD NOT), рекомендуется (RECOMMENDED), возможно/может (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с RFC 2119.

 

Идентификатор архитектуры

 

Каждая архитектура должна предоставлять уникальную, желательно значимый идентификатор, специфичный для данной архитектуры. Это Архитектурный Идентификатор, или АИД (AID). АИД СЛЕДУЕТ быть таким же, как и аннотация Architecture.Name для архитектуры, которая обычно совпадает с названием, используемым во всплывающей подсказке процессора.

 

АИД НЕОБХОДИМО содержать ни одного байта, кроме следующих символов: цифры, буквы в верхнем и нижнем регистрах, точки (.),  дефисы (-), нижние подчёркивания (_), косые черты (/), пробелы. В дополнение, НЕДОПУСТИМО, чтобы АИД начинался с пробела, заканчивался на пробел или содержал в себе последовательность из двух или более пробелов. АИД СЛЕДУЕТ начинаться с заглавной буквы, хотя бы для того, чтобы загрузочный код было легче отличить от других файлов и директорий в листингах.

 

Новый АИД НЕ ДОЛЖЕН содержать пробелов, если это не требуется для совместимости.

 

Архитектуре, имеющей несколько вариантов, которые несовместимы между собой, СЛЕДУЕТ использовать различные АИД для каждого варианта. Резервные схемы, такие как схемы с попыткой использования нескольких АИД специфичны для конкретной архитектуры и не рассматриваются в данном документе.

Образы EEPROM с поддержкой CAB ("CABE-образы")

 

Этот раздел относится к архитектурам, утилитам прошивки EEPROM и любому жёстко запрограммированному загрузочному коду (аналогично machine.lua в "стандартной" архитектуре Lua).

 

Образу EEPROM с поддержкой CAB ("образ CABE") НЕОБХОДИМО начинаться с символов "--[", за которыми следует ноль или более символов "=", а затем "[CABE:" - префиксная строка. CAB-совместимой архитектуре НЕОБХОДИМО быть готовой к работе с любым количеством "=" от 0 до 7, при этом CABE-образ НЕ ДОЛЖЕН использовать более 7.

 

За префиксной строкой следует единственный АИД. Он обозначает "предполагаемую архитектуру" для данного CAB-образа. За ним следует одно из двух значений:

• Двоеточие (:), в случае которого "основное тело" состоит из байтов, следующих за двоеточием, до тех пор, пока не будет встречена корректная суффиксная строка.
• Суффиксная строка, в случае которой "основное тело" состоит из оставшейся части образа, телу НЕОБХОДИМО быть корректным кодом на языке Lua 5.2 И Lua 5.3.

 

"Суффиксная строка" состоит из ASCII "]", за которым следует такое же количество "=", как и в префиксной строке, а затем еще одна "]". Для того чтобы быть корректной суффиксной строкой, ей НЕОБХОДИМО содержать ровно столько же "=", сколько и префиксная строка. В частности, в противном случае допустимая суффиксная строка, содержащая большее количество "=", чем префиксная строка, должна рассматриваться точно так же, как и любая другая последовательность байтов, не являющаяся суффиксной строкой.

 

"Основное тело" содержит фактические данные EEPROM для данной архитектуры. Интерпретация этих данных определяется архитектурой.

 

Если CABE-образ содержит данные после корректной суффиксной строки, то этим данным НЕОБХОДИМО представлять собой код Lua, совместимый с архитектурами Lua 5.2 и 5.3, предоставляемыми OpenComputers. Если архитектура CABE-образа не является таковой, то этому коду СЛЕДУЕТ состоять только из информативного вызова ошибки.

 

Любое отклонение от этого стандарта приводит к появлению не-CABE-образа. Все действия с не-CABE-образами специфичны для конкретной архитектуры, но не-CABE-образ СЛЕДУЕТ обрабатывать так же, как и "основное тело" корректного CABE-образа.

 

Предпочтительным расширением файлов для образов CABE является ".cabe". Предпочтительный тип MIME - "application/x-cabe-image", хотя допустимо использование "application/octet-stream". НЕДОПУСТИМО распространение CABE-образов с использованием любого MIME-типа "text/*", так как это почти наверняка приведет к повреждению бинарных CABE-образов.

 

Приведем пример образа CABE, ориентированного на вымышленную архитектуру "HyperTalk":

--[[CABE:HyperTalk:
ask "What is your name?"
answer "Hello," && it & "!"
]]
error"HyperTalk architecture required"

А вот образ, ориентированный на встроенную архитектуру Lua:

--[[CABE:Lua 5.2]]
for n=1,5 do
  computer.beep(2000, 0.1)
end

Прозрачное переключение архитектуры на основе EEPROM

 

В будущем выпуске OpenComputers может быть добавлена поддержка прозрачного переключения архитектуры с помощью дополнительных данных NBT для EEPROM. Предполагается, что они будут состоять из единственного АИД, идентифицирующего архитектуру, для которой предназначено EEPROM. Данный раздел применяется в случае появления такой поддержки. Для обеспечения согласованности, архитектуры НЕ ДОЛЖНЫ пытаться самостоятельно реализовать такое автоматическое переключение.

Утилите для прошивки EEPROM СЛЕДУЕТ попытаться разобрать все образы как образы CABE. В случае успеха ей СЛЕДУЕТ соответствующим образом пометить EEPROM и записать только "основное тело". В противном случае ей СЛЕДУЕТ удалить из EEPROM все существующие метки архитектуры и записать весь образ.

 

Архитектура, загружающая EEPROM с корректным архитектурным тегом, НЕ ДОЛЖНА также пытаться разобрать его как образ CABE. Архитектуре, загружающей EEPROM без действительной архитектурной метки, СЛЕДУЕТ попытаться разобрать его как образ CABE, и ей НЕДОПУСТИМО самой устанавливать архитектурную метку.

 

Загрузочный код

 

Данный раздел относится к EEPROM, предназначенным для использования в качестве загрузчиков первого этапа, а также к программам, которые должны загружаться с помощью таких EEPROM.

 

Загрузчикам СЛЕДУЕТ, если загрузочная EEPROM содержит UUID загрузочного устройства, попытаться сначала загрузиться с этого устройства. Загрузочная EEPROM содержит UUID загрузочного устройства, если eeprom.getData() полностью состоит из ASCII UUID или если она начинается с ASCII UUID, за которым следует нулевой байт.

 

Управляемый режим (файловые системы)

 

Поведение загрузчика на управляемых файловых системах состоит из следующих действий:

• Если "/<AID>" существует и является директорией, загрузить "/<AID>/boot".
• Если "/<AID>" существует и является файлом, загрузить "/<AID>".
• Все дальнейшие случаи специфичны для конкретной архитектуры.

 

Если одно из вышеперечисленных условий выполняется, но попытка загрузки не удалась, процессу загрузки НЕДОПУСТИМО продолжаться автоматически. Например, если "/<AID>" является директорией, но загрузка "/<AID>/boot" не удалась, то загрузчику НЕОБХОДИМО либо выдать ошибку, либо предложить пользователю предпринять дальнейшие действия.

 

Что именно подразумевается под "загрузкой", специфично для конкретной архитектуры. На архитектуре Lua она заключается в загрузке файла в виде кода Lua и его последующем выполнении. На низкоуровневых архитектурах она может заключаться в загрузке содержимого файла по фиксированному адресу в оперативной памяти и переходе (прыжке) на этот адрес. Архитектурам СЛЕДУЕТ предоставлять стандартный способ для загрузчика первого этапа сообщить загружаемому коду UUID файловой системы, из которой он был загружен.

 

Пример: Рассмотрим загрузку на архитектуре OC-ARM. Загрузчик проверяет, существует ли "/OC-ARM". Он существует и является директорией. Затем загрузчик пытается загрузить "/OC-ARM/boot". Это не удается, поскольку "/OC-ARM/boot" не является корректным. Происходит аварийное завершение работы машины с сообщением об ошибке, объясняющим проблему.

 

Неуправляемый режим (диски)

 

Загрузочный диск, совместимый с CAB, начинается с загрузочного сектора. Этому загрузочному сектору НЕОБХОДИМО быть первым или вторым сектором диска. Если и первый, и второй сектор диска содержат корректный загрузочный сектор, то будет использован только первый. Загрузочный сектор начинается с ASCII-строки "CAB", за которой следует ноль или более текстовых загрузочных записей. Этот список текстовых записей завершается восклицательным знаком. Если за этим восклицательным знаком следует определенная последовательность байтов {0x00, 0x1A, 0xCA, 0xBD} (нулевой байт, маркер конца файла CP/M (исторически таковым не является - прим. пер.), двухбайтовое магическое число), то за ней следуют ноль или более бинарных загрузочных записей, завершаемых нулевым байтом.

 

НЕДОПУСТИМО, чтобы загрузочные записи выходили за пределы загрузочного сектора. Архитектуры МОГУТ определять, что загрузочные записи для данной архитектуры должны быть текстовыми или бинарными, и МОГУТ определять, что бинарные загрузочные записи должны иметь определенный порядок байтов и/или должны быть расположены по секторам. Загрузочным устройствам для архитектур, в которых не указано, что загрузочные записи должны быть текстовыми или бинарными, НЕОБХОДИМО поддерживать оба варианта.

 

Текстовая запись соответствует формату ":<AID>=<offset>+<length>". <AID> - это АИД, для которого предназначен код. <offset> - десятичное число, указывающее смещение байтов, с которого следует начинать чтение, ИЛИ "s", за которым следует десятичное число, указывающее номер сектора, с которого следует начинать чтение. <length> - десятичное число, указывающее количество байт для чтения.

 

Бинарная запись описывается следующей структурой C99:

struct {
  uint8_t record_length;
  uint8_t flags;
  uint16_t load_start;
  uint32_t load_length;
  char aid[];
};

record_length - это число, которое необходимо добавить к смещению данной записи, чтобы пропустить ее. Ему НЕОБХОДИМО быть равным 8 + длина АИД + 1.

 

flags представляет собой битовое поле, для которого определены следующие флаги:

• 0x40: Если установлен, load_start это номер сектора. Если нет, load_start это байтовое смещение.
• 0x80: Если установлен, load_start и load_length установлены в порядке little-endian. Если нет, load_start и load_length находятся в сетевом порядке байт (big-endian).

load_start - это номер сектора либо байтовое смещение, с которого начинается процесс загрузки. load_length - это количество байт для чтения. aid - это АИД предполагаемой архитектуры, которому НЕОБХОДИМО быть нуль-терминированным.

 

Как и в случае с управляемым режимом, действия с загруженными данными специфичны для конкретной архитектуры. Загрузчики, поддерживающие только бинарные записи, должны считать сектор правильным загрузочным сектором, если он начинается с символа "CAB", и находить конец текстовых загрузочных записей, не разбирая их, путем поиска первого "!". Загрузчики, поддерживающие только текстовые записи, не должны учитывать байты, следующие за первым нулевым байтом.

 

Пример 1:

CAB:Lua 5.2=s3+17:Lua 5.3=s3+17:HyperTalk=384+5100!
001A CABD (после ! идёт окончание текстовых записей, после {0x00, 0x1A, 0xCA, 0xBD} идёт начало бинарных записей)
0F (длина первой записи)
C0 (flags - 0x40 + 0x80 - little-endian, смещение сектора)
0900 (начать с сектора номер 9)
0000 0100 (загрузить 65536 байт)
5342 3635 3032 00 (нуль-терминированная строка "SB6502")
00 (бинарных записей больше нет)

Этот диск содержит корректный загрузочный код для Lua 5.2, Lua 5.3, HyperTalk и SB6502. Для Lua 5.2 и 5.3 используется один и тот же загрузочный код длиной 17 байт, начинающийся в начале сектора №3. Загрузочный код HyperTalk имеет длину 5100 байт и начинается с 384 байт диска, что при использовании 256-байтных секторов составляет половину второго сектора. Загрузочный код SB6502 имеет длину 65536 байт и начинается в начале сектора номер 9.

 

Пример 2:

CAB!

Это корректный загрузочный сектор, но он не содержит загрузочных записей.  Это самый надежный способ пометить диск как незагружаемый.

 

---

Источники:
Lizzian, What is OETF?

Solra Bizna, OETF #1: Cross-Architecture Booting (draft)

Принимаются предложения по исправлениям перевода/редактированию.
Все ссылки, кроме ссылки на RFC, были оставлены мной, в остальным старался сохранить оригинальное форматирование.

Изменено 28 июля, 2023 пользователем ov3rwrite

[eu_tomat 2 154]

Для тех, кому лень читать длинный текст:

 

Проблема: Код, записанный в EEPROM и на загрузочных дисках, может быть запущен на процессоре неподходящей архитектуры.

Решение: Описанный в статье стандарт.

 

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

 

Есть похожее предложение по маркировке дисков, но я уже не стал вникать.

 

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

[ECS 1 903]

18 часов назад, eu_tomat сказал:

Для тех, кому лень читать длинный текст: