Как компютрите не работят

24.10.2013

Операционни системи

• Парчета код, които управляват хардуера
• Позволяват изпълнението на потребителски програми
• Има ги разни (Windows/Linux/OS X)

Kernel

• Ядрото (duh) на операционната система
• Има пряк достъп до всичко в компютъра ви
• Грижи се за потребителските програми

Драйвъри

• Парчета код в ядрото, които управляват конкретен хардуер
• Могат да се слагат отделно от ОС-а

Userland

• "GNU" частта от "GNU/Linux"
• Полезните програмки, без които една ОС е безполезна
• Текстови редактори, web browser-и, терминали, графични среди, etc

User space / Kernel space

• Userland частта вървят в първото
• Kernel-a върви във второто
• Това е грубо казано, демек е омешано, но така е в общия случай
• Няма общо с root (Linux)/Administrator (Windows)
• Защо е това разделение?
• Сигурност: между отделните процеси, както и между тях и ядрото

... а какво всъщност са процеси?

• Това са потребителските програми
• Всеки е разделен от всички останали
• Всеки има свое виждане за паметта

... а какво всъщност е виртуална памет?

• Паметта, до която имат достъп процесите
• Те НЯМАТ достъп до истинските адреси във физическата памет
• Всеки процес има собствена като те не се застъпват
• Всеки процес има право да достъпи пълното адресно пространство
• Виртуалната памет може да не е във физическата (swap file, memory mapped files, etc)

Как User space достъпва kernel space

• През така наречените System Calls
• Това са обикновени функции, които можем да викаме
• Намират се в стандартната С блиотека, която върви с всяка ОС
• Те вътрешно ще направят магията
• Магията се нарича interrupt-и

... а какво всъщност са interrupt-и?

• Начин да кажем на ядрото, че искаме нещо да се случи (sys call)
• Както и начин на процесора да каже на ядрото, че нещо е станало (timer interrupt)

Как изглежда един процес във виртуалната памет?

• Всеки процес, очевидно, има изпълним код
• Stacks, heeps, read-only segments
• Отделно има и mapped files, etc

Изпълнимите файлове на твърдия диск

• Съдържа кода на приложението
• Може да съдържа кода на външни библиотеки
• Или просто имената на тези външни зависимости
• Примерна зависмист е стандартната С библиотека

Как получаваме изпълними файлове?

• Чрез компилация и линкване
• Компилацията превежда отделен файл с програмен код към машинни инструкции
• Линкването "свързва" отделни компилирани единици
• Какво правим с външни зависимости, които не са наш код?
• Като например printf от стандартната С библиотека?

Static linking

• Когато кодът на нужните библиотеки е в изпълнимия файл
• В Go става точно така, когато компилираме наше приложение, което import-ва "fmt"

Dynamic linking

• В изпълнимия файл има единствено имена на библиотеки и функции
• Пример: libc.so:printf или msvcrt.dll:printf
• ОС-а се грижи да "зареди" библиотеката и да навърже адресите

static VS dynamic linking

• По-големи изпълними файлове при статично линкване
• Малко по-бързо изпъленение при статично линкване
• Няма споделяне на код в обща библиотека при статично линкване

Въпроси?