LINUX.ORG.RU
← fstream
pygtk - glade или не glade →
Ответ на: комментарий от balodja

Это было моё предложение. «ОС - реализация и блабла» и «Современные ОС».

Я пьян, простите.

anonymous
()

Я брал документы с http://tldp.org
Хорошо написано!
Интересная статья о Play Station там же

impr ★
()

>Слышал много хороших отзывов про Таненбаума, но у него всеже про minix. Может стоит лучше взять что-то по линуксу?

Я бы не советовал изучать строение ОС по линуксу. Потому что бардак это. Общие принципы устройства ОС лучше таки по миниксу2 изучать, имхо.

Но если интересует конкретно линукс, это уже совсем другое дело.

// Я в этом вопросе не мега-спец, поэтому слишком всерьез мое имхо не принимай.

nnz ★★★★
()

Unix изнутри (unix internals), ядро linux (understanding the linux kernel), linux device drivers. Думаю будет достаточно.

frey ★★
()
Ответ на: комментарий от ttnl

Да помниться ты тут устроил хохму насчёт вещественных чисел в ядре, и при этом ссылался на эту мукулатуру :)

anonymous
()

Если тебе интересен UNIX, то могу посоветовать:
«The design of the UNIX operating system» by Maurice J. Bach.
«Unix Internals: The New Frontiers» by Uresh Vahalia.

Есть еще неплохие книги из серии «Design and implementation of XXX-BSD operating system».

Krivenok_Dmitry ★
()

по Plan 9 книжки почитай: http://lsub.org/who/nemo/9.intro.pdf http://lsub.org/who/nemo/9.pdf

Её автор (nemo, один из авторов Plan B) читал в университете курс по операционным системам — ядро, управление памятью, организация процессов, сисколлов. И вместо унылого линукса решил для примера понагляднее взять Plan 9.
Получилось, по-моему, неплохо.

алсо, полезная инфа в смысле практики, не теории, есть на http://wiki.osdev.org/Main_Page . Тут немножко более вялый форум http://osdev.ru/ , а тут http://osdev.sysbin.com/ http://www.sysbin.com/ кондовый, на любителя.

anonymous
()

в общем, основа ядра любой ОС — управление ресурсами. А дальше уже пошли особенности реализации, как именно оно это делает.
Либо построено по образу и подобию исполняемого модуля с библиотеками (монолит), либо само ближе к набору библиотек (микроядро), и тогда нужны какие-то другие базовые концепции для объединения набора в одну кучку — пересылка сообщений в голом виде, как minix, Mach, реализация как в QNX или как в L4, концепции вроде файлов/потоков, как в Plan 9, разделяемая реентерантрая библиотека с библиотеками-драйверами, как в Amiga OS Exec kernel (хотя Plan9 и AmigaOS — вполне себе монолитные ядра, просто гораздо более модульные). Или вообще, абстрактное управление некими абстрактными ресурсами, а какими именно — подсистемы решат, как в экзоядре.

Всё остальное — особенности реализации. «Классическая» школа — запихивать всё в мега-библиотеку и называть её монолитным ведром. Если повезёт выделить стабильное API подсистем, есть шанс сделать его достаточно модульным. Тогда на каждый тип ресурса есть своя отдельная абстракция, и свалено это всё в кучу, в ведро. Например, тип файлов — файл, директория, сокет, пайп, и т.п.
Другой вариант — упор на модульность и унификацию абстракций. К примеру, в Plan9 все ресурсы — это файлы. А как конкретно реализованы — сделано в процессе-сервере ресурсов. Или, процессы-менеджеры ресурсов. Или, подсистемы и общие интерфейсы, как в экзоядрах. Это микроядра или экзоядра.
Другой вопрос, как склеивать эти унифицированные абстракции — вызовом методов внутреннего интерфейса (подсистем) или внешнего (сисколлов), посылкой сообщений, унифицированной VFS.

anonymous
()
Ответ на: комментарий от anonymous

книга «Linkers & Loaders» by John R. Levine app-doc/linkers-and-loaders в Gentoo поможет тебе понять, как работает линкер со стороны компилятора (статический линкер) и загрузка кода из исполняемого файла в процесс (динамический линкер и собсно, лоадер). Это то, что ядро делает после создания нового процесса, распределения ему ресурсов и непосредственно перед выполнением процесса.

Заодно, можешь поэкспериментировать с BareBones tutorials —
1. сделать хелловорд сисколлом, и встроить непосредственно в ядро
2. загрузить «процесс» модулем
3. понять, что нужно реализовать для «обычного» запуска нового процесса.

Это поможет лучше понять различия между кодом в ядре и вне ядра, или драйвером и пользовательским процессом. В реальности, драйвер должен общаться с какой-то подсистемой, поэтому можно читать то же LDD, /usr/src/linux/doc/Stable-API-nonsense.txt (хех), и для сравнения — что-нибудь про те системы, где наоборот, специально старались сделать стабильное API для драйверов: QNX, например.

anonymous
()
Ответ на: комментарий от anonymous

Нуда, там написано, что fpu используется при пересылке большого количества данных (скорее всего в качестве mmx регистров) и при подсчете чексум, в чем собственно хохма? Сейчас, возможно, это и убрали из ядра.

frey ★★
()

С.Хоар, «Взаимодействующие последовательные процессы», сети Петри, линейное программирование и т.п. — позволяют планировать распределение ресурсов и находить дедлоки, клинчи, рейскондишны. Это из теории.
Спинлоки, мьютексы, фьютексы и т.п. — это из практики.
Сюда же можно приписать выделение памяти, стратегии выделения памяти или сборщик мусора — хотя выделение памяти в ядре куда проще, чем GC, если ты понимаешь, как работает GC, ты понимаешь картину в целом.
Выделение времени, разделение времени, квантование, реализация многозадачности и стратегии выделения — помогают понять, какую задачу решает ядро, выполняя процессы многозадачно. И что также, как и с GC, есть стратегии удобные и неудобные в разных случаях, сценариях (см. стратегии планировщика)

anonymous
()
Ответ на: комментарий от anonymous

Если взять к задаче «ядра ОС» и подойти с другой стороны, мы получим частный случай задачи планирования ресурсов (предприятия, например).
С этой точки зрения, можно решать задачу эвристически (книги того же Таненбаума, например — это энциклопедия эвристических методов), формализуя нужные подсистемы с нужной степенью формальности, а можно и напрячься, и построить формальную ТЕОРИЮ ВСЕГО в целом, построить формальную модель ОС.
С формальными моделями есть подходы с двух направлений — во-первых, сертификация и аттестация существующих решений (ОС) на соответствие каким-то формальным критериям (например, «система реального времени со временем реакции ХХХ мсек — это система, в которой любая операция предсказуемо выполняется не более, чем за ХХХ мсек»), или по поддерживаемому внешнему API (POSIX, например — это стандарт на переносимое API). Тут оценивается, конечно же не только ОС, а система в целом на её базе. Но если ОС ничего не может гарантировать, то и система на её основе как правило, тоже. Например, QNX — гарантированно выполняет стандарты POSIX и такие-то стандарты на быстродействие (макс. время вызова сисколлов)
С другой стороны, можно изначально строить модель на соответствие стандартам и критериям. А потом на базе этой модели построить 1) ОС 2) драйвер 3) пользовательское приложение. Это подходы ОС Coyotoshttp://en.wikipedia.org/wiki/Coyotos , House http://en.wikipedia.org/wiki/House_(operating_system) /L4/OK4L и т.п. С точки зрения драйверов, есть DevIL или ещё что-то типа него — описание формальной модели драйвера, автоматическая генерация драйвера из модели, автоматическое обеспечение согласованности API. В ОС применяется свой язык описания модели — BitC в Coyotos/EROS, Haskell в House, и т.п.

anonymous
()
Ответ на: комментарий от ttnl

Почти все 1К страниц автор занимается описанием API, которое в ядре меняется каждый месяц. Уж лучше Лава почитать, чем это.

MuZHiK-2 ★★★★
()

Основы операционных систем. Курс лекций Карпов В.Е., Коньков К.А.

http://www.sprinter.ru/books/1873784.html

Книга легко читается и имеет разумный объем. Состоит из 2-х частей: теория (os independent) + практика программирования (linux). Рекомендую. Через неделю сдаю экзамен авторам :)

mipt_student ★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.
← fstream
Development
pygtk - glade или не glade →