Центр информации по операционным системам: Форумы / Другие ОС / Реально ли сделать простую ОСь своими руками?

Центр информации по операционным системам :: Форумы :: Операционные системы :: Другие ОС		<< Предыдущая тема \| Следующая тема >>
Реально ли сделать простую ОСь своими руками?

Переход на страницу 1 2 3 ... 10 [11] 12 13
Модераторы: Roman I Khimov, Wanderer, Dron

Автор

Добавил

Dron

Вторник 30.03.2010 14:57

ID пользователя #13

Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651

prog8 написал(а) ...

Dron написал(а) ...
ожидать готовности порта здесь уже не нужно.

...Но нужно ожидать готовности драйвера? Или просто у него есть очередь сообщений, приложения шлют драйверу сообщения и ждут ответа, а драйвер разгребает их в меру сил в порядке очереди? (Это у меня в os9 так, кстати.)

Приложения не шлют ничего, они у меня просто приходят...

Драйвер сам в состоянии ожидать свою готовность. Я так полагаю что обмен между приложениями идет не на уровне микросекунд - а на уровне данных протокола. Ну всмысле с уровня портов мы уже поднялись на уровень предментной области. По мелочам мы не размениваемся. Хотя это и не означает что мы работаем только с гигантскими данными...

prog8 написал(а) ...
Я избегаю излишнего создания нитей, мне кажется, это слишком увеличивает накладные расходы системы

Да, создание нитей не очень легкая техника. Но мне кажется современные системы плохо дружат с современным многоядерным железом именно потому, что пренебрегают нитями. Все современные (популярные имею ввиду) системы родились в те времена - когда нитей не было, и нити для них достаточно чужды.

В то время как я например могу (в случае сильных тормозов

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

Там простор для оптимизации большой. Если понадобиться.

Отвечая на другой вопрос: Многопроцессорности и сетей у меня пока нету. У меня даже консоли нормальной нету. А ядро в состоянии редизайна. Уже второй год..

prog8 написал(а) ...
И вопрос: а как у тебя поддерживается чтение, ограниченное тайм-аутом? Если я всего лишь хочу прочитать данные из последовательного порта, но ждать при этом не дольше одной миллисекунды, боюсь, возня с созданием новой нити сожрет эту мою миллисекунду с потрохами.

Вызовы у меня устроены так, что приложение приходит со своими данными(могут быть и нулевого размера) в надежде получить ответ(опционально).

При этом приложение может осуществлять вызов асинхронно. То есть сформировать запрос, дернуть сервис и продолжить свою работу.

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

Вообще ядерное API в этой версии ядра у меня стало довольно таки неудобно. Вызовы стали проще, но иногда их приходится дергать пачками.
Но я сознательно выбрал простоту и логичность...

prog8 написал(а) ...

Dron написал(а) ...
У меня все в системе на способностях строится...

Но кто определяет, можешь ты, или нет? Наверно, ядро, кому еще?

Правами доступа рулят приложения. Если приложение создает некий ресурс - оно может его кому нибудь дать с определенными ограничениями.

или может даже сделать этот ресурс публично доступным.

PS: И еще - про ожидания... Ожидание события ИМХО не обязательно связано с материальной выгодой.

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

Или абстрактный клик левой кнопкой мыши... То есть просто событие... Наверное правильно рассматривать событие - как некий сигнал... А вот сигнал к чему... это уже второй воспрос. Может быть просто продолжить работу, Может быть прочитать какие нибудь данные, может быть завершить работу...

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

А когда речь идет о данных - то разговор о нескольких получателях ИМХО неуместен. Драка начнется - здесь должен стоять один получатель - сплиттер, который разделит данные по справедливости.

Как пример можно привести TCP... IP идут сплошным потоком, но приложениям нельзя разрешать выбирать себе интересующие их фреймы.. нужен контроль. - Соответственно сплиттер делит IP поток на TCP потоки и уже к ним предоставляет доступ приложениям - каждое к своему потоку.

[ Редактирование Вторник 30.03.2010 15:04 ]

Одну из двух вечных российских проблем можно, в принципе, решить с помощью асфальтоукладчиков и катков. А вот с дорогами, конечно, будет труднее...

Андрей Валяев

Наверх

prog8

Вторник 30.03.2010 22:40

ID пользователя #1343

Зарегистрирован: Пятница 26.03.2010 07:27
Сообщений: 27

Честно говоря, так и не понял, что значит "приложения приходят" ))
Ну да ладно, не важно. Я решил остановиться на модели "каждая нить ждет или чего-то конкретного, или чего угодно", при этом будильнику дается право будить кого угодно. Буду реализовывать. А если в процессе что-то сильно не понравиться, буду иметь в виду запасной вариант "а-ля select".

Пока думал о событиях, пришел к выводу, что менеджмент памяти, который уже был написан, надо бы переписать... Много думать - вредно для дела.

Наверх

Dron

Вторник 30.03.2010 22:46

ID пользователя #13

Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651

prog8 написал(а) ...
Честно говоря, так и не понял, что значит "приложения приходят" ))

У меня нету сообщений, у меня нету сокетов...
У меня только TPC... TPC - это типа RPC.. вызов функций..

Приложение - сервер создает точку доступа.
Приложение - клиент вызывает эту точку, передавая при этом запрос и получая ответ по завершению обработчика.

Андрей Валяев

Наверх

prog8

Вторник 30.03.2010 22:55

ID пользователя #1343

Зарегистрирован: Пятница 26.03.2010 07:27
Сообщений: 27

Да, еще в качестве пояснения: у меня нет понятий "процесса" и "адресного пространства". Совсем. Только "нити", которые работают в едином адресном пространстве. Архитектура блэкфина не поддерживает виртуальную адресацию. Я уверен, что это сделано из маркетинговых соображений, так как блэкфин - совместный проект АДИ и Интела. Но именно по этой причине мне собственно и пришлось писать свою ось - портировать какую либо готовую просто нереально, они все заточены под полноценные ММУ с виртуализацией (кроме МС-ДОСа, наверно, но ДОС нам не подходит). А вот неплохо получается, мне нравится то, что я придумал, должна получиться интересная и довольно необычная система. Может, по случаю дисер напишу, типа "Использование экзоядерной технологии на процессорах без виртуализации".

Наверх

prog8

Вторник 30.03.2010 22:59

ID пользователя #1343

Зарегистрирован: Пятница 26.03.2010 07:27
Сообщений: 27

Понял, спасибо!
Тоже думал было сделать такую штуку для "сигналов" - как сисвызов signal() в юниксе, там функция-обработчик назначается. Но так сходу показалось сложновато, и я решил, что сделаю, как только понадобится. Пока не понадобилось.

Наверх

Dron

Вторник 30.03.2010 23:06

ID пользователя #13

Зарегистрирован: Понедельник 05.07.2004 11:16
Местонахождение: Москва
Сообщений: 651

В принципе линукс умеет работать без MMU.
Но мне без MMU скучно...

А процессы у меня есть - процесс - это типа объединяющая нити сущность

Андрей Валяев

Наверх

prog8

Среда 31.03.2010 06:14

ID пользователя #1343

Зарегистрирован: Пятница 26.03.2010 07:27
Сообщений: 27

Dron написал(а) ...
линукс умеет работать без MMU

Да, правда не "настоящий", а специальный порт под микроконтроллеры - uCLinux. И даже есть порт под блэкфин. Я с ним некоторое время повозился, но на наших платах он так у меня и не заработал. И я решил, что выгоднее будет написать свою систему, все-таки линукс - крупная вещь, если что-то пойдет не так, трудно будет разбираться.
Мне еще RTEMS понравилась, но тоже не осилил. Может, просто не хватило тогда знаний и опыта. Зато теперь у меня есть и опыт, и своя система, так что не жалею.

Наверх

prog8

Понедельник 19.07.2010 08:13

ID пользователя #1343

Зарегистрирован: Пятница 26.03.2010 07:27
Сообщений: 27

К сожалению, только сейчас приступил к написанию ядра своей новой системы (beeks). Буквально на следующий день после предыдущего моего поста начальство велело срочно делать то-то, то-то и то-то (заказчики требуют), так что работу над системой в очередной раз пришлось отложить. Ну да ладно, дело не в этом.
Возникла опять концептуальная проблема, которую хочется обсудить со знающими людьми. Суть в следующем.
У меня память четко закреплена за субъектами, ее использующими; при этом читать разрешено всем, а писать только владельцу. Субъектов три вида - ядро, приложения и "интерфейсы" (по сути программные модули, работающие с процессорной периферией в режиме супервизора). У интерфейсов тоже есть своя память, в которую они что-то пишут, в частности, принимаемые от периферии данные. Раньше процесс, желая получить данные, мог просто передать интерфейсу адрес своего буфера и его размер, и интерфейс спокойно туда писал и по некоторому условию возвращал управление приложению. Теперь же интерфейсу запрещено писать в буфер приложения, и поэтому схема взаймодействия процессов и интерфейсов усложнилась, и то, что я придумал, мне не очень нравится.
Приложение через последовательность вызовов добирается до драйвера, который все еще является пользовательской функцией, но при этом умеет работать с интерфейсом; и вот драйвер, чтобы принять от интерфейса данные в переданные ему приложением буфер, должен (через ядро) передать интерфейсу информацию "нужны данные при таких-то условиях"; при этом ядро понимает "нужны (ожидаю) данные", а интерфейс понимает условия. Процесс становится ожидающим события, а интерфейс записывает себе условия, и как только они наступают, сообщает ядру "ожидаемые таким-то процессом условия выполнены, событие наступило". Ядро смотрит, ждет ли процесс все еще этого события, если да, будит его. Процесс (фактически, драйвер) теперь знает, что у интерфейса есть то, что ему (процессу) нужно, и... И что? Он должен как-то забрать данные. Допустим, есть функция, которая умеет работать со структурами интерфейса, но при этом выполняется в контексте процесса; драйвер вызвает эту функцию, в ней данные переписываются в буфер приложения, после чего процесс снова должен обратиться к интерфейсу, и сказать "я забрал у тебя данные (там-то, столько-то)", после чего они (процесс и интерфейс) могут друг о друге забыть до следующего раза. Еще важно, чтобы между объявлением интерфейса о наступлении события и получением им уведомления от процесса о заборе данных никакой другой процесс не мог вмешаться в эту транзакцию, а это значит, что ядро должно придержать другие процессы, если они вдруг кинутся с обращаниями к этому интерфейсу.
Не нравится мне в этой схеме сложность разработки драйверов; в сущности, задача драйвера - правильно построить общение с конкретным устройством, используя некие "стандартные" механизмы, предоставляемые интерфейсом (к кторому нужное устройство как раз подключено), а получается, что драйверу приходится очень много внимания уделять правильному общению с интерфейсом. Из-за подобной проблемы у меня разработка os9 зашла в тупик, потому что там главной заботой драйверов стало аккуратное разгребание очереди сообщений, которые им валятся со всех сторон. Боюсь, как бы история не повторилась.
Что скажете, знающие люди? Как в других системах сделано, например, получение шеллом вводимой с клавиатуры строки?

Наверх

alman

Пятница 10.12.2010 23:07

ID пользователя #753

Зарегистрирован: Суббота 28.10.2006 01:21
Местонахождение: планета Земля
Сообщений: 95

prog8 написал(а) ...

Как в других системах сделано, например, получение шеллом вводимой с клавиатуры строки?

Unix Shell никогда не обращается к драйверам напрямую, а обращается к операционной системе. В ядре реализована прослойка между драйвером устройства и его логическим представлением в /dev/.

В юниксах нет понятия клавиатуры, но есть понятие консоль.

Наверх

prog8

Вторник 14.12.2010 06:26

ID пользователя #1343

Зарегистрирован: Пятница 26.03.2010 07:27
Сообщений: 27

alman, спасибо за соучастие, а чего сказать-то хотел? По каким понятиям живет юникс я более-менее в курсе, но интересуют подробности. Вот, нажал я клавишу. Контроллер (который в самой клавиатуре) это дело распознал, и...? Что дальше? Послал нечто через провода. Что именно? Куда? Кому? Контроллер на материнке что сделал? Как ядро общается с контроллером? А если клавиатура USB? В какой момент она становится консолью? Какие буферы имеются, сколько, как устроены, для чего нужны, как к ним организован доступ ядру, драйверам, приложениям? Какой путь проделывают данные, прежде чем их поймает шелл, кто и когда переводит скан-код в ASCII, сколько при этом задействовано драйверов, сисвызовов, прерываний? Как передаются данные (изначально - информация о факте нажатия определенной клавиши, в итоге - появление символа во входном потоке приложения) между участвующими субъектами?
Такие вот вопросы возникают.

И кстати. Ось опять отложена на неопределенный срок.

Наверх

Переход на страницу 1 2 3 ... 10 [11] 12 13
Перейти: Наверх