Mac Buster wrote:
Согласен на 128 байт ?. Если уж "припрет" со свободным местом, можно урезать
до 80 байт.
При небольшой длине командной строки не будет возможности полноценно работать
с файлами из терминала, либо потребуется ограничить длину названия файлов и
каталогов вместе с глубиной их вложенности, как в MS-DOS. Такое мне совсем не
нравится.
На счет глубины вложенности каталогов и длины имен файлов - я думаю здесь
нужно остановиться на каком-то разумном пределе, будет лучше для самого же
пользователя. Тогда сразу вопрос в догонку: что можно сделать при 63 кило
памяти, отпускаемых программам, чего нельзя бы сделать c 62 кило ?.
Т.е. я хочу сказать - если тебе нужна длинная консольная строка, то почему
бы не увеличить "префикс" программ до 0x800 ?. С лихвой хватит и на ком.
строку, и на служебные буферы. А на счет длины строки, думаю разумным преде-
лом будет 2-3 сотни байт (3-4 строки ширины экрана). Кста, заюзать сейчас
весь префикс в 0x800 совсем не обязательно, надо зарезервировать часть на
будущее. Сколько ты хочешь отвести под консольную строку ?.
Хотя связываться с чем-то другим, кроме линейного списка (поиска), целесо-
образно лишь для вместительных каталогов, что применительно к Спринтеру imho
начинается где-нить с нескольких сотен файлов на каталог. Кто-что думает ?.
Ограничивать пользователя нехорошо
Согласен, но все хорошо в меру
в первую очередь придется прикручивать функции I/O для Биоса. Без них будет
как в вакууме, вообще никакой связи с девайсами.
Согласен. Впрочем, на начальной стадии можно вообще без конкретной файловой
системы обойтись при загрузке монтируя RAM-диск и закидывать туда файлы
средствами Estex.
Согласен, на начальном этапе будет не до FS, когда будут обкатываться
I/O процедуры. Их можно проверить и под Estex. Как будут готовы процедуры
чтения и записи fdd, hdd (cd-rom можно позже прикрутить), то надо переходить
на кодение FS. Здесь желательно бы отдельному челу (еще лучше челам) начать
писать другие процедуры Биоса, которых потребуется целая куча (и время на
это). Можно определить каждому свой "класс" функций, который тот будет кодить.
К примеру вывод в текстовом режиме, вывод в графическом режиме, работа с
окнами (менеджер окон), работа с клавой, менеджер памяти и т.д.
Для ядра ОСи ты еще не проектировал отдельные группы процедур "верхнего
уровня" ?, т.е. набор функций ввода/вывода, манипуляция с памятью, диспетчер
программ (сюда же imho нужно включить работу с семафорами), управление драй-
верами, чем должно заниматься ядро. Кста, что еще должно делать ядро, кроме
того, что я перечислил ?. Должно ли ядро заниматься графикой ?.
Не уверен, что в ядро нужно прилинковывать работу с родной FS, это imho лучше
сделать на уровне подключаемого (и соотв. заменяемого) модуля. Тогда можно
будет отлаживать разные FS без переделки самого ядра. Т.е. разделить мух и
котлеты

.
Imho разумным решением будет делать однопользовательскую ОС, не в пример
юниксам ?. Ни к чему это, да и кодить будет гораздо проще, не потребуется
везде отслеживать права доступа к файлам.
P.S. Пока идет обсуждение ОСи, высказываются разные мысли, ты у себя тем
временем из этой инфы создавай стандарт (доку) для своей ОСи. Чтобы потом
эти соображения не канули в историю.