Fanatic wrote:
По какой причине?
Главным образом, по идеологической.
Fanatic wrote:
Почему ядро неспособно обращаться ко всем требуемым для его работы файлам, если они расположены непосредственно на носителе, рядом с ним?
Потому что для работы с носителем нужен ещё и драйвер носителя. Драйвер IDE встроен в ядро только по историческим соображениям. Как и файловые системы, впрочем. Драйвера USB-флешек и SATA - отдельные файлы, которые надо прочитать до того, как будет возможна полноценная работа.
Fanatic wrote:
И последнее: известно, что такая возможность была раньше. Почему сейчас вопрос с обсуждаемым обстоит как "невозможно", вместо "теоретически возможно, но работа не гарантируется"?
Она и раньше скорее не работала, чем работала. Минус полтора метра памяти под неиспользуемый рамдиск, жёсткая привязка к координатам на IDE, необходимость наличия DOS. И главное - отсутствие поддержки при изменениях ядра, которых с того момента было много.
Fanatic wrote:
Исходя из теории, загрузчик должен передавать управление ядру ОС, которое, в свою очередь, загружает всё что ему требуется в память ОЗУ.
У вас неточные представления о теории. Загрузчик должен загрузить не только ядро ОС, но и данные, необходимые для инициализации. В Linux точно так же грузится образ рамдиска, только там он read-only и, соответственно, не FAT, а что-то вроде squashfs. В Windows загрузчик читает реестр и загружает драйверы, указанные в нём.
Fanatic wrote:
Над чем конкретно и какие именно потребуются усилия чтобы реализовать требуемое?
Есть вариант заставить загрузчик создавать FAT-образ динамически при загрузке по отдельным файлам, чтобы с точки зрения ядра оставался /rd/1, но kolibri.img был бы виртуальной сущностью, не присутствующей в виде отдельного файла. Для не слишком толкового, но и не совсем бестолкового, разработчика - ориентировочно месяц разработки.