Алан Кокс представил Unix-подобную ОС Fuzix, ядро которой потребляет около 40 Кб ОЗУ

[Eltaron]

Слушай, а для работы инита обязательно нужен tty1 ?

А какие проблемы?
mknod /dev/tty1 20666 257 - и вуаля, создали tty1

---------- Post added at 13:21 ---------- Previous post was at 13:18 ----------

Я Makefile немного причесал и добавил скрипт для определения путей SDCC.
Плюс - в libclean вставил автоопределение местоположения z80.lib

Да, я всё хочу это в апстрим запушить.
Один твой коммит уже там https://github.com/EtchedPixels/FUZIX/commit/a13208b Вычищать из него, правда, пришлось практически всё - ты одновременно и обрезание \r закоммитил. Это не круто, когда такие принципиально разные вещи в одном коммите пушатся.

[Advertiser]

[Error404]

А какие проблемы?
mknod /dev/tty1 20666 257 - и вуаля, создали tty1

---------- Post added at 13:21 ---------- Previous post was at 13:18 ----------


Да, я всё хочу это в апстрим запушить.
Один твой коммит уже там https://github.com/EtchedPixels/FUZIX/commit/a13208b Вычищать из него, правда, пришлось практически всё - ты одновременно и обрезание \r закоммитил. Это не круто, когда такие принципиально разные вещи в одном коммите пушатся.

На AIX так:
mknod Name { b | c } Major Minor
т.е. все понятно и логично - класс устройства и экземпляр (индекс). Т.е. мажорный и минорный номера, обычно они небольшого значения (ибо типов и экземпляров устройств немного). А что есть цифры 20666 и 257? Почему такие большие значения?

[Eltaron]

А что есть цифры 20666 и 257? Почему такие большие значения?

20666 - права. Символьное устройство, доступ всем на чтение-запись.
257 = 256 + 1, major = 1, minor = 1

[SfS]

Вычищать из него, правда, пришлось практически всё - ты одновременно и обрезание \r закоммитил. Это не круто, когда такие принципиально разные вещи в одном коммите пушатся.

Это да. Но вырезание '\r' вещь для линукса необходимая.
Кстати, там кроме вырезания ещё и автоформатирование С-файлов. Иначе некоторые вообще нечитаемы были.

---------- Post added at 14:34 ---------- Previous post was at 14:31 ----------

А какие проблемы?
mknod /dev/tty1 20666 257 - и вуаля, создали tty1[COLOR="Silver"]

да я сейчас на работе, так что просто исходники рассматриваю) про mknod мы знаем. нас етому учили)

[Eltaron]

Кстати, там кроме вырезания ещё и автоформатирование С-файлов. Иначе некоторые вообще нечитаемы были.

Это у тебя длина табуляции стоит неверная

Я лично стараюсь вообще эту всю мелочь типа концов строк и форматирования не трогать. Смысла мало - ну, если компилятор не ругается, - а риск нарваться на merge conflict вырастает на порядки.

[Error404]

Подскажите еще вопросик: как (где) в пространстве процесса FUSIХ хранятся:
- пареметры переданные программе (процессу) при запуске (т.е. то, что в CP/M кладется по адресу 0x80..0xFF)
- переменные окружения (environment)

[Eltaron]

Подскажите еще вопросик: как (где) в пространстве процесса FUSIХ хранятся:
- пареметры переданные программе (процессу) при запуске (т.е. то, что в CP/M кладется по адресу 0x80..0xFF)
- переменные окружения (environment)

Судя по всему, прямо под UDATA. Функция wargs их кладет (link). Любопытно, пересекается с UDATA_STASH. Впрочем, она 768 байт, всем хватит.

[Error404]

Судя по всему, прямо под UDATA. Функция wargs их кладет (link). Любопытно, пересекается с UDATA_STASH. Впрочем, она 768 байт, всем хватит.

вот кстати это тоже зацепило: 768 байт, откуда, зачем? Ведь на UZIX, к примеру, sizeof(udata)=119 байт.
Или он расширил ее на размер стринговых параметров которые в некоторых функциях (в мало каких функциях, иногда, один-два параметра char[]) передаются ядру - чтобы оно сразу копировалось в страницу ядра?

[b2m]

вот кстати это тоже зацепило: 768 байт, откуда, зачем? Ведь на UZIX, к примеру, sizeof(udata)=119 байт.
Или он расширил ее на размер стринговых параметров которые в некоторых функциях (в мало каких функциях, иногда, один-два параметра char[]) передаются ядру - чтобы оно сразу копировалось в страницу ядра?

Скрытый текст

/* This is the user data structure, padded out to 512 bytes with the
 * System Stack.
 */
typedef struct u_block {
        u_data u_d;
        char   u_s [512 - sizeof(struct u_data)];
} u_block;

[свернуть]

Плюс 256 байт на стек для прерывания (интересно нафига).

[Eltaron]

вот кстати это тоже зацепило: 768 байт, откуда, зачем? Ведь на UZIX, к примеру, sizeof(udata)=119 байт.

Стек процесса ещё рядом лежит.

А вот стек прерывания... Окей, зачем его в common держать - я понимаю. Но зачем копировать туда-сюда?

---------- Post added at 16:05 ---------- Previous post was at 16:01 ----------

А хотя догадываюсь. Эти 256 байт - это стек прерывания только на время прерывания. В остальное время это как раз хранилище переменных окружения и аргументов командной строки.