сепарация на адресни пространства, protected mode, context switching и т.н Това е едното
16-битовите x86 процесори някъде до 386 не са подържали виртуална памет, вместо това паметта се разглежда относително линейно (има сегментация, но за да опростим нещата, нека речем че просто имаш един линеен изглед към оперативната памет, с 20-битово адресиране). Няма и никакъв механизъм за защита на паметта - всеки може да чете и да пише. Това ти е т.нар "real mode" и при това положение не можеш да имаш многозадачна ОС. Причини за това много, например близко до ума е че един процес може да чете и пише в същата памет, в която друг процес чете и пише, съотвено такава система би била доста нестабилна, с нулева сигурност.
Някъде с 80386 се въвежда т.нар "protected mode" с истинска виртуална памет и 4 нива на привилегии, съответно можеш да имаш kernel работещ с най-високите привилегии и множество потребителски процеси. Всеки процес има собствено адресно пространство и това става благодарение на собствен набор page таблици, които map-ват виртуални към физически адреси. При това положение ако всичко е организирано как трябва, един процес не може да ака в паметта, ползвана от друг, един процес не може да срине цялата система и т.н.
context switching-а е процеса при който многозадачната операционна система "превключва" потребителските процеси, изпълняващи се на процесора. Това включва запазване на състоянието на регистрите на стария процес, изчистване на процесорния кеш, възтановяване на регистрите на новия процес.
Многозадачните операционни системи не са започнали с линукс. Не са започнали и с юникс ако трябва да сме точни, концепциите за виртуална памет и превключване на процеси, съществуват вероятно над 10 години отпреди да се появи юникс. В x86 света обаче това се случва някъде в средата на 80-те с първите 386-ци. Така че това не е някаква революция, просто от един момент хардуерът започва да го позволява. Линукс просто има щастието да се появи във време, когато 32-битовите x86 архитектури вече са доминиращи. Та си няма история подобна на тази с DOS.
Още повече, имам основания да считам че не можеш дори най-общо да ми опишеш какво се случва когато някоя програма направи нещо просто, като например да изчете един ред от един текстов файл. Съмнява ме да знаеш нито механизма по който се прехвърляме в kernel mode, нито кой слой се занимава с какво, нито какво става ако имаме вече кеширани въпросните блокове, нито начина по който кешираната информация се организира в паметта и да не продължавам. Значи за каква архитектура точно говорим? ----Това е второто
Е можеш ли?
VFS слоя ---това е следващото
linux ядрото е организирано на до голяма степен на слоеве. VFS слоя е този, който се занимава с файловите системи. Има едно абстрактно API, което дава начин на разработчиците на файлови системи лесно да ги реализират - регистрираш си callback-ове свързани с определен набор операции и правиш каквото трябва да правиш. VFS слоя е инфраструктурата, която вика въпросните callback-ове когато трябва и си комуникира с останалите слоеве в ядрото когато трябва.
Ама продължи нататък бе Firmware-а на харддиска на сървъра, BIOS-а на сървъра, съответните еквиваленти на клиентската машина, IOS-ите на рутерите и по-умните суичове по пътя. Както и разбира се уиндоуса на пича Свободният софтуер е навсякъде ---това си е заяждане нали ?
Да, това беше заяждане на тема "всичко което виждаш е свободен софтуер"
Също така, за въпросният файл няма изискване да бъде на системния диск. Или може би сериозно мислиш, че четенето от swap файла/диска трябва да минава през VFS/block кеширането...хммм. Съветвам те да провериш що е то O_DIRECT, защо е възникнало и откъде е черпено вдъхновение. Не е силно свързано точно с този въпрос, ама знам ли, може да получиш някакво просветление ---ТОВА е следващото.
Може би трябва да започнем оттам защо според теб е лоша идея swap-а да е върху файл.
Отново стана роман работата
Сега и какво аз знам за цялата работа
Знам че в линукс API-то се нарича линукс а в уиндоус winapi или win32 #тук очаквам да ме поправиш в линкс основната библиотека е glibc а във уиндоус е c runtime
Не, в линукс основната C библиотека е libc. На теория не е проблем програма писана на друг език и компилирана, да върви върху линукс. Основните функции са реализирани чрез low-level интерфейс, по-правилната дума е ABI, не API. Въпросният интерфейс е реализиран чрез софтуерно прекъсване, int 80h.
В Windows задачите се изпълняват от висок приоритет към нисък, докато при Linux редът на изпълнение на опашката със задачите е от приоритет означен с малка цифра към приоритет с по-голяма цифра.Приоритетите в Linux са от 0 до 139, а в Windows от 31 до 1 и това е:)
Това е кое?