Если ты начинаешь с самого нуля, то вероятно первое, что нужно сделать - это написать пакет функций и макросов, которые облегчат программирование архитектуры x86, и следовательно - жизнь разработчику ОС. Ну а человек с большими амбициями может даже попытаться сделать эти функции портабельными :)

(Если ты не заинтересован в написании низкоуровнего, взаимодействующего с аппаратурой кода, то я посоветую Utah Oskit, где много чего было на эту тему сделано) Так же тебе понадобится разработать пакет стандартных библиотечных функций, которые бы могло использовать ядро: strcmp(), strcpy().. плюс отладочные функции вроде assert() и panic().

В это же время придется принять архитектурные решения, от которых будет зависеть дальнейшая разработка "высокоуровневой" части ОС. Чем раньше ты сделаешь выбор, тем лучше, т.к. переписывать уже написанный код - не самое приятное занятие.

Первая головная боль - модель памяти. Сегментация И/ИЛИ страничная адресация? Похоже, что в наше время большинство людей предпочитают страничную адресацию без сегментации, потому что модель памяти 'flat' более приятна для разработчика, кроме того сегментация непортабельна в отличие от страничной адресации

Где в памяти будет находится ядро? Будет ли у процессов отдельные адресные пространства, или все будут находиться в одном? Как насчет виртуальной памяти?

Теперь многозадачность/многопоточность. Если конечно ты решишь их использовать. Возможно ли, что когда-нибудь эта система будет работать на многопроцессорной машине? Если да, то лучше делать всю синхронизационную фигню в самом начале, ибо вставлять ее потом - хуже ночных кошмаров.

Какая будет модель процессов? Обычная двухуровневая (процессы и потоки), или нечто более другое? (Я использую трехуровневую (ИнтерактивнаяСессия владеет процессами, а те - потоками). Собираешься ли ты использовать TSS при переключении задач, или используешь программное переключение?

Системные вызовы. Как ты их сделаешь? Здесь есть несколько вариантов: Linux использует программные прерывания, другие варианты - шлюзы вызова. Можно сделать только один шлюз вызова, для вызова функции межпроцессного взаимодействия, и реализовать все остальное внутри IPC (даже при взаимодействии внутри ядра).

Кстати, об IPC - Порты сообщений? Pipes? Очереди? Локальные сокеты? Все вышеперечисленное? Лучше подумать об этом сейчас, потому что выбор модели IPC очень сильно повлияет на ядро. Еще следует подумать о сетевом взаимодействии.

Драйвера устройств - что ты думаешь о них? И о файловой системе. Можно использовать UNIX-модель - где все является файлами.

Безопасность! Если в твоей системе она будет, то опять же нужно подумать о ней в самом начале. Вставлять безопасность потом еще хуже чем SMP, если ты конечно не хочешь, чтобы твоя система напоминала дуршлаг. Есть множество способов реализовать секьюрность, например использовать ACL (листы контроля доступа).

Ф-ф-фух, с дизайном вроде все. И запомни, чем больше ты решишь в начале, тем реже тебе придется переписывать систему с нуля.

Перейдем к практике. Как только ты начнешь кодить ОС, не забудь о примитивном драйвере консоли (только для того, чтобы выводить информацию на экран). Пытаться отладить ядро ОС без printf() - безумство.

Первое что тебе понадобится - это загрузчик. Можно написать свой, а можно заюзать что-нибудь вроде GRUB. (свой написать ты всегда успеешь).

Затем напиши что-нибудь, что выведет надпись на экран. Как только ты *увидишь*, что твоя ОС делает что-то, сразу почувствуешь прилив сил!

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

Ну а все остальное очень сильно зависит от принятых решений по поводу дизайна...