fk0123 (15.11.2014 23:55, просмотров: 1) ответил VVB на Кто-нибудь использует RTOS (не ядра) в своих проектах? Интересует их работа в защищённом режиме, взаимодействие пользовательского кода с периферией (как я понимаю, через вызов функций RTOS, ни один пользовательский код не должен обращаться
п.1 это скорей "мелкие технические подробности" вызванные использованием функций libc в ядре, как я понимаю. п.2 -- две кучи это от бедности (отсутствия MMU). В нормальных ОС куча у каждой задачи своя. А память выделяется линейно через sbrk(). Но как так сделаешь, линейное выделение, без MMU-то? Никак. Потому и две кучи. Одна на все задачи, и одна на ядро. Чтоб если задача где-то нарушила, то хоть чтоб ядро не падало. Полумера ещё та. Причём здесь стек вообще не понял. Подразумевается, чтоб куча не под стеком лежит (как в классическом unix). Причём TLS не понял тоже. Хотя там что-то подобное есть -- посмотри на реализацию errno. Он для каждого треда (а не только задачи) отдельный. Да, с пунктом 3 именно так. Что используют в России? Да ничего не используют. Пишут говнокод попроще и побыстрей. Говорят "а мы не используем библиотечных функций" или "errno нам не нужен, ошибки мы не обрабатываем", "исключений у нас нет, т.к. с ними код толстый и опять же ошибки"... Нормальное программирование экономически не выгодно. Чтоб писать хороший и правильный код в хороших и правильных операционках, с купленным а не ворованным софтом нужно каждую строчку твоего кода продать 100500 раз впоследствии. Каким бы ты не был суперпрограммистом. Фирма где ты трудоустроен на такое способна?
Как писать драйвера -- POSIX ни к месту упомянут. Писать так же как и обычный софт. Что там необычного. Нужно продумать интерфейс к системным вызовам (read, write, open, ioctl...) и реализовать весь функционал через него. Для чего-то вроде block device или character device всё достаточно очевидно. Для чего-то вроде звука или видео может быть не удобно лишний раз копировать и разумней будет сделать асинхронный ввод-вывод сразу в пользовательскую память. Там весь интерфейс окажется внутри ioctl(), нужно будет предусмотреть свой набор функций через ioctl() вызываемых. Архитектурно -- драйвер может иметь обработчики прерываний и какой-то механизм bottom halves, что-то вроде kernel-space процесса, и функции вызываемые через системные вызовы. С callbacks из драйвера сложно, впрочем их можно отобразить на сигналы.
)