Розрахунок по базовим дисциплінам планування. Операційні системи FreeBSD та Linux

Размещено на http://www.allbest.ru/

Міністерство освіти і науки, молоді та спорту України

Полтавський національний технічний університет

імені Юрія Кондратюка

Кафедра комп'ютерної інженерії

КУРСОВИЙ ПРОЕКТ

з навчальної дисципліни

«Системне програмне забезпечення»

Тема: Ч.1 «Розрахунок по базовим дисциплінам планування»

Ч.2 «Інсталяція операційної системи FreeBSD»

Ч.3 «Відпрацювання теоретичного завдання по операційним системам Linux»

Перевірив

Гроза Петро Миколайович

Полтава 2014

Частина 1. Розрахунок по базовим дисциплінам планування

1.1 Теоретична частина

1.1.1 Поняття дисциплін планування

Дисципліна планування - одна з ключових концепцій в багатозадачності і багатопроцесорних систем, як в операційних системах загального призначення, так і вопераційних системах реального часу.

1.1.2 Необхідність використання дисциплін планування

Необхідність використання дисциплін планування являється в тому, щоб ефективно навантажувати систему.

Для забезпечення загальної продуктивності системи потрібно:

· Використання процесора -- дати завдання процесору, якщо це можливо.

· Пропускна здатність -- кількість процесів, що виконуються за одиницю часу.

· Час на завдання -- кількість часу, для повного виконання певного процесу.

· Очікування -- кількість часу, який процес очікує в черзі готових.

· Час відповіді -- час, який проходить від подання запиту до першої відповіді на запит.

· Справедливість -- рівність процесорного часу для кожного процесу.

1.1.3 Базові дисципліни планування

FCFS (first come - first serve - першим прийшов - першим обслуговується) - проста дисципліна, робота якої зрозуміла з її назви. Це дисципліна без витіснення, тобто, процес, вибраний для виконання на ЦП, не уривається, поки не завершиться (або не перейде в стан очікування за власною ініціативою). Як дисципліна без витіснення, FCFS забезпечує мінімум накладних витрат. Середній втрачений час при застосуванні цієї дисципліни не залежить від тривалості процесу, але штрафне відношення при рівному втраченому часі буде великим для коротких процесів. Тому дисципліна FCFS вважається кращою для довгих процесів. Істотною гідністю цієї дисципліни, разом з її простотою, є та обставина, що FCFS гарантує відсутність нескінченного відкладання процесів: будь-який процес, що поступив в систему, врешті-решт буде виконаний незалежно від ступеня завантаження системи.

RR (roundrobin - карусель) - проста дисципліна з витісненням. Процес отримує в своє розпорядження ЦП на деякий квант часу Q (у простому випадку розмір кванта фіксований). Якщо за час Q процес не завершився, він витісняється з ЦП і прямує в кінець черги готових процесів, де чекає виділення йому наступного кванта, і так далі. Показники ефективності RR істотно залежать від вибору величини кванта Q. RR забезпечує якнайкращі показники, якщо тривалість більшості процесів наближається до розміру кванта, але не перевершує його. Тоді більшість процесів укладаються в один квант і не стають в чергу повторно. При величині кванта, прагнучій до нескінченності, RR вироджується в FCFS. При Q, прагнучому до 0, накладні витрати на перемикання процесів зростають настільки, що поглинають весь ресурс ЦП. RR забезпечує якнайкращі показники справедливості: штрафне відношення P на великій ділянці тривалості процесів t залишається практично постійним. Тільки на ділянці t < Q штрафне відношення починає змінюватися і при зменшенні t від Q до 0 зростає експоненціально.

SJN (shortest job next - найкоротша робота - наступна) - невитісняюча дисципліна, в якій найвищий пріоритет має найкоротший процес. Для того, щоб застосовувати цю дисципліну, повинна бути відома тривалість процесу - задаватися користувачем або обчислюватися методом екстраполяції. Для коротких процесів SJN забезпечує кращі показники, чим RR, як по втраченому часу, так і по штрафному відношенню. SJN забезпечує максимальну пропускну спроможність системи - виконання максимального числа процесів в одиницю часу, але показники для довгих процесів значно гірші, а при високому ступені завантаження системи активізація довгих процесів може відкладатися до безкінечності. Штрафне відношення слабо змінюється на основному інтервалі значень t, але значно зростає для найкоротших процесів: такий процес під час вступу до системи має найвищий пріоритет, але вимушений чекати, поки закінчиться поточний активний процес.

PSJN (preemptive SJN - SJN звитісненням) - поточний активний процес уривається, якщо його час виконання, щозалишився, більший, ніжуновоприбулогопроцесу. Дисципліна забезпечує ще більшу перевагу коротким процесам перед довгими. Зокрема, в ній усувається те зростання штрафного відношення для найкоротших процесів, яке має місце в SJN.

HPRN (highest penalty ratio next - з найбільшим штрафним відношенням - наступний) - дисципліна без витіснення, що забезпечує якнайкращі показники справедливості. Це досягається за рахунок динамічного перевизначення пріоритетів. Всякий раз при звільненні

ЦП для всіх готових процесів обчислюється поточне штрафне відношення:

p[i]=(w[i]+t[i]) / t[i]

де i - номер процесу; w[i] - час, витрачений процесом на очікування; t[i] - тривалість процесу - передзадана або прогнозована. Для процесу p[i], що тільки що поступив=1. ЦП віддається процесу, що має найбільше значення p[i]. Для коротких процесів HPRN забезпечує приблизно ті ж показники справедливості, що і SJN, для довгих - ближчі до FCFS. На великому діапазоні середньої тривалості процесів показники, забезпечувані HPRN, представляють середнє між SJN і FCFS і слабо залежать від тривалості. Ще одна гідність HPRN - в тому, що в часі очікування може враховуватися (з деякими ваговими коефіцієнтами) і очікування в інших чергах і, таким чином, виконується більш комплексний облік завантаження системи. Істотним недоліком методу є необхідність перевычисления штрафного відношення для всіх процесів при кожному перемиканні, що погано узгоджується із загальною політикою мінімізації накладних витрат в дисциплінах без витіснення.

SRR (selfish RR - егоїстичний RR) - метод з витісненням, що дає додаткові переваги виконуваним процесам, що дозволяє підвищити пропускну спроможність. Всі процеси розділяються на дві категорії - нові і вибрані. Новими вважаються ті процеси, які не отримали ще жодного кванта часу ЦП, решта всіх процесів - вибрані. Під час вступу до системи кожному процесу дається деякий пріоритет P0, однаковий для всіх процесів, який надалі зростає. В кінці кожного кванта часу перераховуються пріоритети всіх процесів, причому пріоритети нових процесів зростають на величину dA, а вибраних - на величину dB. ЦП віддається процесу з найвищим пріоритетом, а при рівності пріоритетів - тому, який раніше поставлений в чергу.

Показники дисципліни істотно залежать від вибраного співвідношення між dA і dB. При dB/dA=1 дисципліна вироджується в звичайну RR, при dB >> dA - в FCFS. Власне дисципліна SRR забезпечується в діапазоні значень 0<dB/dA<1.

FB (foreground-background - передний-задний плани) - черга готових процесів розщеплюється на дві підчерги - черга переднього плану і черга заднього плану. Черги обслуговуються по дисципліні RR, але чергу переднього плану має абсолютний пріоритет: поки в ній є процеси, черга заднього плану не обслуговується.

Новий процес прямує в чергу переднього плану. Якщо процес використовував встановлене число N квантів в черзі переднього плану, але не завершився, він переводиться в чергу заднього плану.

Узагальнення дисципліни FB на n черг з номерами 0, 1..., n-1 і з абсолютними пріоритетами, що убувають при зростанні номера черги, носить назву MLFB (multiply level feed back - багаторівневі черги із зворотним зв'язком). Розщеплювання черги готових процесів на дві і більш за підчергу забезпечує селекцію процесів по тривалості - довші процеси потрапляють в черзі з великими номерами і, відповідно, з меншими пріоритетами. Дисципліна MLFB дуже ефективна для систем, що працюють в інтерактивному режимі.

1.1.4 Реалізація планування у Linux

Розглянемо два варіанти реалізації планування в Linux - традиційну (належить до ядер версій до 2.4 включно) і нову, включену в ядро версії 2.6.

Ядро Linux при плануванні не розрізняє процеси і потоки,тому для визначеності ми надалі говоритимемо про планування процесів.

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

Стосовно процесів реального часу, достатньо сказати, що:

вони завжди матимуть під час планування пріоритет перед звичайними процесами;

процес із плануванням за принципом FIFO виконують доти, поки він сам не віддасть процесор (наприклад, в наслідок призупинення або завершення) або поки він не буде витиснений процесом реального часу із вищим пріоритетом; те саме стосується процесу із круговим плануванням, крім того, що він додатково буде витіснений після вичерпання кванта часу.

Розглянемо алгоритм планування звичайних процесів. В основі алгоритму лежить розподіл процесорного часу на епохи (epochs). Упродовж епохи кожен процес має квант часу, довжину якого розраховують у момент початку епохи. Здебільшого різні процеси мають кванти різної довжини. Коли процес вичерпав свій квант, його витісняють і протягом поточної епохи він більше не виконуватиметься. Керування віддають іншому процесові. Якщо ж процес був призупинений для виконання введення-виведення або внаслідок синхронізації, його квант не вважають вичерпаним і він може бути вичерпаний планувальником упродовж поточної епохи. Епоха закінчується, коли всі готові до виконання процеси вичерпали свої кванти. У цьому разі алгоритм планування перераховує кванти для всіх процесів і розпочинає нову епоху.

Квант, який задають на початку епохи, називають базовим квантом часу процесу. Його значення можуть динамічно змінюватися системними викликами nice() і setpriority(). Процес-нащадок завжди успадковує базовий квант свого предка.

Пріоритет процесу буває двох видів: фіксований, для процесів реального часу, що задають тільки під час створення процесу, та динамічний, для звичайних процесів, який залежить від базового пріоритету і часу, що залишився до вичерпання кванта. Динамічний пріоритет будь-якого звичайного процесу завжди нижчий за будь-який пріоритет процесу реального часу.

Опишемо найважливіші поля структури даних процесу стосовно планування:

policy - визначає, до якої групи відноситься процес (звичайні, реального часу за алгоритмом FIFO тощо);

nice - задає величину, на якій грунтується базовий квант часу процесу (надалі для спрощення вважатимемо nice рівним базовому кванту, насправді ц не зовсім так);

counter - містить кількість переривань таймера, що залишилися до вичерпання кванту процесу. На початку епохи counter надають значення базового кванта і зменшують його на одиницю в обробнику переривання таймера.

Умови виклику процедури планування

Розглянемо ситуації, коли відбувається виклик процедури планування (її називають scedule()).

Коли процес повинен бути заблокований через те, що потрібний йому ресурс у цей час недоступний. У цьому разі його керуючий блок спочатку додають у відповідну чергу очікування, а потім відбувається перепланування.

За допомогою відкладеного запуску (lazy invocation). Відкладений запуск полягає в тому, що що у певний момент часу спеціальному полю need_reschedструктури процесу надають значення 1. Це відбувається в таких випадках: коли поточний процес вичерпав свій квант; коли у стан готовності переходить процес, пріоритет якого вищий, ніж у поточного; коли процес явно поступається своїм правом виконання через відповідний системний виклик. При цьому негайно перепланування не відбувається, але пізніше, коли цей процес повинен знову отримати керування після переривання, він перевіряє, чи не дорівнює поле need_resched одиниці. Якщо рівність виконується, запускають процедуру планування.

Початок нової епохи

Особлива ситуація виникає тоді, коли для всіх процесів у черзі готових процесів значення динамічного пріоритету дорівнює нулю, тобто всі вони вичерпали свій квант і настав час починати нову епоху. Проте це не означає, що система взагалі не має процесів, для яких квант не вичерпаний, -- вони можуть перебувати в чер­гах очікування (найчастіше це процеси, обмежені введенням-виведенням). Коли розпочинається нова епоха, відбувається перерахування квантів для всіх процесів системи (не тільки для процесів у стані готовності). При цьому довжину кванта для кожного процесу задають рівною сумі його базового пріоритету і половини частини кванта, що залишилася в нього:

for_each_task (р)

p.counter = (p.counter / 2) + p.nice;

Оскільки до початку нової епохи ненульовий квант залишається тільки у про­цесів, які не перебувають у стані готовності, цей алгоритм надає певну перевагу процесам, обмеженим можливостями введення-виведення. При цьому значення кванта для процесу ніколи не зможе стати більшим, ніж подвоєне значення його базового пріоритету.

Перерахування кванта під час створення нового процесу

Тепер розглянемо, що відбувається під час створення нового процесу. Найпростіше рішення (копіювати значення counter у структуру даних нащадка) може призвести до того, що процеси будуть штучно подовжувати свій квант створенням нових нащадків, виконуючих той самий код. Для того щоб цьому перешкодити, після функції fork значення counter розділяють навпіл: одна половина переходить нащадкові, інша залишається предкові.

Недоліки алгоритму.

*Вибір процесу для виконання відбувається внаслідок розрахунку динамічного пріоритету для всіх процесів у черзі готових процесів. Зі збільшенням кількості готових процесів у системі переглядати цю чергу від початку до кінця під час кожного виклику процедури планування стає невигідно.

*Якщо кількість процесів буде дуже великою, перерахування всіх динамічних пріоритетів на початку нової епохи може виконуватися досить довго. З іншого боку, епохи змінюються рідше, що більше в системі процесів.

*Алгоритм розрахований на зменшення часу відгуку для процесів, обмежених можливостями введення-виведення, навіть якщо вони не є інтерактивними (наприклад, фоновий процес індексації пошукової системи) і не потребують малого часу відгуку.

*Зі збільшенням кількості процесорів підтримувати загальні черги, які не вра­ховують наявність різних процесорів, стає невигідно.

1.1.5 Опис дисципліни у відповідності до варіанту номера студента N_i. Недолік дисципліни планування

Характеристика процесів по дисципліні HPRN

} дисципліна без витиснення

} забезпечує найкращі показники справедливості за рахунок динамічного перерахунку пріоритетів

} при звільненні CPU для готових процесів обчислюється поточне штрафне відношення

де i - номер процесу

wi - час, витрачений процесом на очікування

ti - попередньо задана або прогнозована тривалість процесу

} pi=1 - для процесу, що надійшов

} CPU віддається процесу з max pi

Переваги

} для коротких процесів показники справедливості близькі до SJN

} для довгих показники близькі до FCFS

} для діапазону середніх процесів показники - середнє між SJN і FCFS і мало залежать від протяжності процесу

} в часі очікування може враховуватися і очікування в інших чергах

Недолік

} необхідно перерахувати штрафне відношення для всіх процесів при перемиканні

1.2 Розрахункова частина

Планування процесів по дисципліні HPRN - завдання

Задача

ь У системі перебувають процеси A, B, С, D, Е з тривалістю , , , , відповідно.

ь Процеси надходить в систему в моменти , , , , .

Процеси надходить в систему в момент часу,, , ,

Час перебування процесу в системі, , ,,,, відповідно.

На часовій діаграмі кожний прямокутник представляє інтервал часу, протягом якого процес перебуває в системі Під шкалою часу показані стани процесів у кожний момент часу:

ь "а" - для активного процесу

ь "а" - для неактивного процесу

Опис діаграми

при звільненні CPU для готових процесів обчислюється поточне штрафне відношення

де i - номер процесу

wi - час, витрачений процесом на очікування

ti - попередньо задана або прогнозована тривалість процесу

Варіант даних Dj
D7	5	6	8	4	7	4	0	8	12	3

P5	HPRN, з найбільшим штрафним відношенням - наступний

Размещено на http://www.allbest.ru/

Опис діаграми: процеси поступають у наступному порядку: В(6), оскільки він є першим порівняно з точкою відліку(з нулем). Наступним кроком ми вводимо в систему процес А(5). Рахуємо його штрафне відношення

де i - номер процесу

wi - час, витрачений процесом на очікування

ti - попередньо задана або прогнозована тривалість процесу

.

Позначаємо процес Е(7). Рахуємо штрафне відношення для нього - 1.37. Оскільки штрафне відношення для процесу А більше, ніж для процесу Е(7), то А(5) виконуватиметься перший(згідно з дисципліною HPRN). Далі рахуємо відношення для процесів С(8) i D(4) відповідно. Для процесу С(8) воно становитиме 2.07, а для процесу D(4) 2.25. Звідси очевидно, що процес D(4) буде виконуватися одразу після закінчення процесу Е(7), а С(8) буде чекати своєї черги аж до закінчення D(4).

Частина 2. Інсталяція операційної системи FreBSD

2.1 Теоретична частина

2.1.1 Види інсталяцій операційної системи FreeBsd, та ситуації в яких вони рекомендуються здійснювати

a) Оновлення до FreeBsd - це доповнення програмного забезпечення. Відомі корпораціїї, наприклад Microsoft постійно оновляють своє ПЗ, постійно думають про своїх користувачів, на сьогодні це досить популярно і актуально.

b) Standard - як правило використовують недосвідчені користувачі, які неорієнтуються у даній операційній системі, тобто мають досить низький рівень знань у даній галузі.

с) Express - встановлення використовують більш досвідчені користувачі, які мали досвід роботи з даним програмним забезпеченням.

Недолік - відсутність вибору конкретних модулів, а просто звичайне швидке встановлення.

d) Custom - використовують досвідчені користувачі, які орієнтуються в необхідних модулях для роботи ПЗ. Необхідні високі знання у роботі з даним програмним забезпеченням.

2.1.2 Види файових систем, їх недоліки та переваги

Файлові системи - невід'ємна частина будь-якої операційної системи. Вони дозволяють користувачам записувати і зберігати файли, отримувати доступ до даних, і, звичайно-ж, користуватися жорсткими дисками. У різних операційних систем є одна спільна риса - їх основна файлова система (native filesystem). Для FreeBSD це Fast File System (або FFS), яка пішла від Unix ™ File System.

FreeBSD також підтримує ряд інших файлових систем, тим самим надаючи можливість отримувати доступ до даних від інших операційних систем локально, наприклад: до даних, що знаходяться на підключених USB пристроях збереження, флеш-накопичувачах і жорстких дисках.

FreeBSD підтримує ряд інших файлових систем.

a) UFS

Компакт-диски з файловою системою UFS можуть бути змонтовані без всяких проблем. Монтування файлових систем Digital UNIX чи інших систем, що підтримують UFS, може бути більш складним, залежно від особливостей розбиття диска конкретною операційною системою.

UnixFilesystem -- файлова система, створена для операційних систем сімейства BSD і зараз використовується у переробленому і доповненому вигляді як основна в операційних системах-потомках (FreeBSD, OpenBSD, NetBSD).

b) ext2/ext3

FreeBSD підтримує розділи ext2fs та ext3fs

ext2 або 2-га розширена файлова система -- файлова система для ядра Linux. Розроблена RйmyCard'ом як заміна для extendedfilesystem. Вона достатньо швидка для того, щоб служити еталоном в тестах продуктивності файлових систем. Вона не є журнальованою файловою системою, і це її основний недолік. Розвитком ext2 стала журнальована файлова система ext3, повністю сумісна з ext2.

ext3 -- журнальована файлова система, що використовується в операційних системах на ядрі Linux, є файловою системої за замовчуванням у багатьох дистрибутивах. Базується на ФС ext2.

Файлова система ext3 може підтримувати файли розміром до 1 ТБ.

c) NTFS

Під FreeBSD є драйвер доступу до NTFS в режимі тільки для читання. Порт ntfs-3g також підтримує операції запису на NTFS

NTFS (New Technology File System -- «файлова система нової технології») -- стандартна файлова система для сімейства операційних систем Microsoft WindowsNT.

NTFS підтримує систему метаданих і використовує спеціалізовані структури даних для зберігання інформації про файли для поліпшення продуктивності, надійності і ефективності використання дискового простору.NTFS має вбудовані можливості розмежовувати доступ до даних для різних користувачів і груп користувачів, а також призначати квоти (обмеження на максимальний обсяг дискового простору, займаний тими чи іншими користувачами). NTFS використовує систему журналювання для підвищення надійності файлової системи. У Файловій системі NTFS відсутнє разділення на атрибути.

d) FAT

Під FreeBSD є драйвер для роботи з FAT в режимі читання-запису.

FAT (File Allocation Table) -Таблиця розміщення файлів. Існує декілька версій FAT, а саме FAT12, FAT16, FAT32. Число в абревіатурі вказує розмір елемента таблиці в бітах. Одиницею розподіленої пам'яті є кластер.

У FAT12 не можна було створити папку, усі файли розміщувалися у головному каталозі (прямо на диску).

e) ReiserFS

Під FreeBSD є драйвер для роботи з ReiserFS в режимі тільки для читання.

ReiserFS -- журнальована файлова система, розроблена спеціально для Linux компанією «Namesys». В даний час ReiserFS підтримується тільки під GNU /Linux, але в майбутньому може бути перенесена на інші платформи.

- Reiser3 може бути пошкоджена в результаті перебудови дерева під час перевірки. Перебудова дерева потрібна за умови, якщо метадані дуже сильно пошкоджені.

- Версії ReiserFS, включені в ядро Linux молодше версії 2.4.10, визнані нестабільними компанією «Namesys» і не рекомендовані для промислового використання, особливо у зв'язці з NFS.

- Невідомий спосіб дефрагментації, крім повного дампа ФС і наступного відновлення. Проте є переупаковщик для ReiserFS v4, який піклується про фрагментацію файлів.

f) ZFS:

На момент написання FreeBSD включає в себе порт драйвера для роботи з Sun ™ ZFS.

ZFS (ZettabyteFileSystem) -- файлова система, створена в корпорації SunMicrosystems для операційної системи Solaris.

Ця файлова система підтримує великі об'єми даних, об'єднує концепції файлової системи і менеджера логічних дисків (томів), інноваційну структуру даних на дисках, легковагі файлові системи

(lightweightfilesystems), а також просте управління об'ємами зберігання даних. Основна перевага ZFS -- відсутність фрагментації даних, що дозволяє динамічно виділяти або звільняти дисковий простір логічній файловій системі, причому цей простір може бути як в рамках фізичного накопичувача, так і розосередженим по декількох мережевих дисках.

Крім того, ZFS має змінний розмір блоку, що кращим чином впливає на продуктивність, паралельність виконання операцій читання-запису, а також 64-розрядний механізм використання контрольних сум, що зводить до мінімуму ймовірність руйнування даних.

Недоліки:

· ZFS не підтримує розподіл квот для кожного користувача або групи. Замість цього, можна створювати ФС для користувачів, кожна з яких матиме своє обмеження розміру. Низький рівень накладних витрат ZFS робить це практичним навіть для багатьох користувачів (але це може значно уповільнити запуск системи). В дійсності, немає жодного практичного рішення проблеми квоти в системах, де файлові системи розділені серед декількох користувачів (як наприклад проекти групи), де дані не можуть бути відокремлені для кожного користувача, хоча це можна здійснити поверх стека ZFS.

· Розширення ємкості зазвичай досягається додаванням груп дисків як віртуальний пристрій (смуга, RAID-Z, RAID-Z2, або дзеркало). Знов записані дані динамічно починатимуть використовувати всі доступні пристрої. Також можливо розширити масив ітераційно замінюючи диски меншої ємкості на диски більшої ємкості та чекаючи на ZFS,

щоб полагодити себе -- час полагодження залежатиме від кількості збереженої інформації, не розмір дисків. Якщо протягом цього процесу зробити знімок, це викличе перезапуск полагодження.

· Зараз не можливо скоротити число пристроїв в накопичувачі або зменшити ємкість накопичувача.

· Не можливо додати диска до пристроїв RAID-Z або RAID-Z2. Ця особливість здається дуже важкою для здійснення. Проте є можливість створити новий RAIDZ пристрій і додати його до пулу.

· Не можливо додавати до пулу пристрої різних типів. Наприклад, якщо ви маєте смуговий ZFS накопичувач, що складається з дисків на SAN, ви не можете додати локальні диски як дзеркальний пристрій.

· Переконфігурація накопичувача вимагає копіювання даних, знищування пулу, і відтворення накопичувача з новою конфігурацією.

· ZFS не є кластером, розподіленою файловою системою абопаралельною файловою системою і не може забезпечити одночасний доступ для багатьох клієнтів таким же чином як до локальної файлової системи. планування віртуальний машина linux

2.1.3 Що включає в себе поняття «Настройка FreeBsd»? Перерахувати компоненти

До налаштування можна віднести:

Налаштування пароля root:

Супер-користувачеві повинен бути встановлений пароль. Зверніть увагу, що при введенні пароля символи, що вводиться не відображаються на екрані. Після введення пароля, він повинен бути введений знову. Це допомагає запобігти друкарським помилкам.

Налаштування мережевих інтерфейсів:

Список всіх мережевих інтерфейсів, виявлених на комп'ютері відображається поруч. Виберіть одну, щоб налаштувати.

Налаштування бездротового мережевого інтерфейсу:

Якщо всі налаштунки бездротової мережі обрані, потрібно ввести пароль, щоб дозволити йому підключитися до мережі.

Бездротові мережі позначаються Ідентифікатор мережі або SSID. SSID є коротким, унікальні ім'я, дане кожнній мережі.

Налаштування IPv4 мережі

Виберіть, чи буде IPv4 мережа використовуватися. Це найбільш поширений тип мережевого з'єднання.

Існують два методи IPv4 конфігурації. DHCP автоматичне налаштування мережевого інтерфейсу правильно, і є кращим методом. Статична конфігурація вимагає ручного введення інформації про мережу.

Примітка: не вводьте випадкової інформації мережі, так як вона не буде працювати.

IPv4 DHCPавтоматичне налаштування(якщо доступно).

IPv4 статичну налаштування мережі

Статичної конфігурації мережевого інтерфейсу вимагає введення деякої IPv4 інформації.

· IP-адреса - вручну призначений IPv4-адрес, який присвоюється цьому комп'ютерові. Ця адреса має бути унікальною і не може вже використовуватись іншим обладнанням в локальній мережі.

· Маска підмережі - маска підмережі використовується для локальної мережі. Як правило, це 255.255.255.0.

· Шлюз - IP-адреса маршрутизатора за замовчуванням у цій мережі. Зазвичай це адреса маршрутизатора або іншого обладнанням мережі, яка з'єднує локальну мережу з інтернетом.

Установка часового поясу

Установка часового поясу на комп'ютері дозволить автоматично вносити поправки за місцевим часом і правильно виконувати інші дії пов'язані з часовим поясом функції належним чином.

Ваш вибір буде залежати від вашого географічного положення.

Виберіть регіон

Виберіть країну

Додавання користувачів

Додавання хоча б одного користувача під час установки дозволяє системі використовуватися без входу під супер користувачем (root). Коли увійшли в систему як root, немає ніяких обмежень по суті або захисту від того, що може бути зроблено. Вхід у систему як звичайний користувач є більш надійним і безпечним.

Введіть інформацію для користувача, щоб додати нового користувача.

Інформація про користувача

· Username - ім'я, яке користувач буде вводити для входу в систему Зазвичай перші літери їх імен у поєднанні з їх прізвищем.

· Full name - повне ім'я користувача.

· Uid - User ID. Як правило, це залишається порожньою, так що система буде використовувати значення.

· Login group - групи користувачів. Зазвичай залишена порожньою, щоб прийняти стандартні.

· Enter password again - Необхідно набрати пароль ще раз для підтвердження.

Final Configuration

Після всього, що було встановлено і налаштовано, надається останній шанс, можливість змінити параметри.

2.2 Практична частина

Етапи виконання

1) Запускаю програмуVMware

2) Створюю нову віртуальну машину для ОС FreeBsd під ім'ям «FreeBsdBRUS» - параметр Virtual machine name. Розмір диску8 Гb - параметр Disk size.

3) В привод потрібно вставити образ диску «FreeBSD-8.1-RELEASE-i386-disc1»

Встановлення ОС відповідно до етапів вказаних у файлі «УСТАНОВКА И НАСТРОЙКА ОС FREEBSD.doc».

4)Запускаємо установку FreeBSD, відразу пропонується вибрати регіон.

5)Після вибору первинних налаштувань з'явиться вікно sysinstall в якому потрібно вибрати для недосвідчених користувачів standard instalation.

6)Потрібно розбити диск на слайси.(Знімок екрану 1)

7)Так як дана ОС єдина на цьому ПК(чи віртуальній машині) підійде менеджер завантаження Standard.

8)Розбиваємо диск на розділи як зазначено у завданні(Знімок екрану 2)

9) Метод встановленни з CD/DVD (Знімок екрану 3)

10) Мережеве налаштування

11) Налаштування консолі (Знімок екрану 4)

12) Налаштування годинника

13) Додавання користувача, але перед цим потрібно створити нову групу, а потім додати юзера (Знімок екрану 5)

14) Встановлення паролю для root

15) Налаштування мережевих пристроїв

16) Остання можливість змінити налаштунки перед закінченням установки FreeBSD.

Частина 3. Відпрацювання теоретичного завдання по операційним системам Linux

3.1 Теоретична частина

Модулі ядра Linux, що динамічно підвантажуються: механізм завантаження-вивантаження

Модуль ядра (англ. loadable kernel module, LKM) - об'єкт, що містить код, який розширює функціональність запущеного або базового ядра ОС. Більшість поточних систем, заснованих на Unix і Windows, підтримують завантажувані модулі ядра, хоча вони можуть називатися по-різному (наприклад, kernel loadable module в FreeBSD і kernel extension в Mac OS X).

Розглянемо, яким чином використовуються різні режими процесора під час взаємодії між ядром і застосуваннями.

Після завантаження ядро перемикає процесор у привілейований режим і отримує цілковитий контроль над комп'ютером. Кожне застосування запускається і виконується в режимі користувача, де воно не має доступу до ресурсів ядра й інших програм. Коли потрібно виконати дію, реалізовану в ядрі, застосування робить системний виклик (system call). Ядро перехоплює його, перемикає процесор у привілейований режим, виконує дію, перемикає процесор назад у режим користувача і повертає результат застосування.

Системний виклик виконується повільніше за виклик функції, реалізованої в режимі користувача, через те що процесор двічі перемикається між режимами. Для підвищення продуктивності в деяких ОС частина функціональності реалізована в режимі користувача, тому для доступу до неї системні виклики використовувати не потрібно.

Завантажувані модулі ядра Linux завантажуються за допомогою команди modprobe. Зазвичай вони знаходяться в каталозі / lib / modules і мають розширення «.Ko» («kernel object») для ядер з версії 2.6, і «.O» для ядер молодших версій.

Ядро - це та частина операційної системи, робота якої повністю прихована від користувача, так, як користувач з ним не працює напряму: користувач працює з програмами. Але, тим не менш, без ядра неможлива робота жодної програми, тобто вони без нього недієздатні. Цей механізм чимось нагадує відносини офіціанта і клієнта : робота хорошого офіціанта повинна бути практично не помітна для клієнта, але без офіціанта клієнт не зможе передати замовлення кухареві, і це замовлення не буде доставлене.

Linux реалізує технологію монолітного ядра. Весь код і структури даних ядра перебувають в одному адресному просторі. Сам термін « моноліт » говорить про те, що в ядрі сконцентровано все, і, за логікою, нічого не може в нього додаватися або видалятися. У випадку з ядром Linux - це правдиво лише частково: ядро Linux може працювати в такому режимі, однак, у переважній більшості збірок можлива модифікація частини коду ядра без його перекомпіляції, і навіть без його вивантаження. Це досягається шляхом завантаження і вивантаження деяких частин ядра, які називаються модулями. Найчастіше в процесі роботи необхідно підключати модулі драйверів пристроїв, підтримки криптографічних алгоритмів, мережевих засобів, і, щоб уміти це правильно робити, потрібно розбиратися в будові ядра і вміти правильно працювати з його модулями.

У ядрі можна виділити кілька функціональних компонентів.

* Планувальник процесів - відповідає за реалізацію багатозадачності в системі (обробка переривань, робота з таймером, створення і завершення процесів, перемикання контексту).

* Менеджер пам'яті - виділяє окремий адресний простір для кожного процесу і реалізує підтримку віртуальної пам'яті.

* Віртуальна файлова система - надає універсальний інтерфейс взаємодії з різними файловими системами та пристроями введння-виведення.

* Драйвери пристроїв - забезпечують безпосередню роботу з периферійними пристроями. Доступ до них здійснюється через інтерфейс віртуальної файлової системи.

* Мережний інтерфейс - забезпечує доступ до реалізації мережних прото-колів і драйверів мережних пристроїв.

* Підсистема міжпроцесової взаємодії - пропонує механізми, які дають змогу різним процесам у системі обмінюваться даними між собою.

Деякі із цих підсистем є логічними компонентами системи, вони завантажуються у пам'ять разом із ядром і залишаються там постійно. Компоненти інших підсистем (наприклад, драйвери пристроїв) вигідно реалізовувати так, щоб їх код міг завантажуватия у пам'ять на вимогу. Для розв'язання цього завдання Linux і підтримує концепцію модулів ядра.

Модулі ядра

Як було вище сказано, ядро Linux дає можливість на вимогу завантажувати у пам'ять і вивантажувати з неї окремі секції коду. Такі секції називають модулями ядра (kernel modules) і виконують у привілейованому режимі.

Модулі ядра надають низку переваг.

* Код модулів може завантажуватися в пам'ять у процесі роботи системи, що спрощує налагодження компонентів ядра, насамперед драйверів.

* З'являється можливість змінювати набір компонентів ядра під час виконання: ті з них, які в цей момент не використовуються, можна не завантажувати у пам'ять.

* Модулі є винятком із правила, за яким код, що розширює функції ядра, відповідно до ліцензії Linux має бути відкритим. Це дає змогу виробникам апаратного забезпечення розробляти драйвери під Linux, навіть якщо не заплановано надавати доступ до їхнього вихідного коду.

Підтримка модулів у Linux складається із трьох компонентів.

* Засоби керування модулями дають можливість завантажувати модулі у пам'ять і здійснювати обмін даними між модулями та іншою частиною ядра.

* Засоби реєстрації драйверів дозволяють модулям повідомляти іншу частину ядра про те, що новий драйвер став доступним.

* Засоби розв'язання конфліктів дають змогу драйверам пристроїв резервувати апаратні ресурси і захищати їх від випадкового використання іншими драйверами.

Один модуль може зареєструвати кілька драйверів, якщо це потрібно (наприклад, для двох різних механізмів доступу до пристрою).

Модулі можуть бути завантажені заздалегідь - під час старту системи (завантажувальні модулі) або у процесі виконання програми, яка викликає їхні функції. Після завантаження код модуля перебуває в тому ж самому адресному просторі, що й інший код ядра. Помилка в модулі є критичною для системи.

Особливості системних бібліотек

Системні бібліотеки Linux є динамічними бібліотеками, котрі завантажуються у пам'ять тільки тоді, коли у них виникає потреба. Вони виконують ряд функцій:

* реалізацію пакувальників системних викликів;

* розширення функціональності системних викликів (до таких бібліотек належить бібліотека введення-виведення мови С, яка реалізує на основі системних викликів такі функції, як printf();

* реалізацію службових функцій режиму користувача (сортування, функції обробки рядків тощо).

У сучасних ядрах при підключенні обладнання модулі підключаються автоматично, а ця подія обробляється демоном udev, який створює відповідний файл пристрою в каталозі " / dev ". Все це виконується в тому випадку, якщо відповідний модуль коректно встановлений в дерево модулів. У випадку з файловими системами ситуація та ж: при спробі монтування файлової системи ядро підвантажує необхідний модуль автоматично, і виконує монтування.

Якщо необхідність в модулі не так на стільки очевидна, ядро його не завантажувати самостійно. Наприклад, для підтримки функції шифрування на loop пристрої потрібно вручну довантажити модуль « cryptoloop », а для безпосереднього шифрування - модуль алгоритму шифрування, наприклад « blowfish ».

Завантаження та вивантаження модулів

Як було вище сказано, завантажити модуль в ядро можна за допомогою двох команд: «insmod» і «modprobe», що відрізняються один від одного можливістю прорахунку і задоволення залежностей. Команда « insmod » завантажує конкретний файл з розширенням « ko », при цьому, якщо модуль залежить від інших модулів, ще не завантажених в ядро, команда видасть помилку, і не завантажить модуль. Команда « modprobe » працює тільки з деревом модулів, і можливе завантаження тільки звідти по імені модуля, а не по імені файлу. Звідси випливає область застосування цих команд: за допомогою «insmod» подгружается файл модуля з довільного місця файлової системи (наприклад, користувач скомпілював модулі і перед перенесенням в дерево ядра вирішив перевірити його працездатність), а «modprobe» - для підвантаження вже готових модулів, включених в дерево модулів поточній версії ядра. У більшості дистрибутивів Linux, утиліти modprobe, insmod, depmod входять до складу пакету modutils mod-utils.

Для завантаження модуля ядра «rt73usb» з дерева ядра, включаючи всі залежності, і відключивши апаратне шифрування, потрібно виконати команду:

# Modprobe rt73usb nohwcrypt = 0

Завантаження цього модуля командою «insmod» відбудеться в такий спосіб :

# Insmod / lib/modules/2.6.38-gentoo-r1/kernel/drivers/net/wireless/rt2x00/rt73usb.ko nohwcrypt = 0

Але потрібно пам'ятати, що при використанні «insmod» всі залежності доведеться довантажувати вручну. Тому ця команда поступово витісняється командою «modprobe».

Після завантаження модуля можна перевірити його наявність у списку завантажених в ядро модулів за допомогою команди « lsmod »

Після вивантаження модуля всі можливості, які він надавав, будуть видалені з таблиці ядра.

Для автоматичного завантаження модулів у різних дистрибутивах передбачені різні механізми. Існує досить дієвий метод завантаження: за допомогою стартових скриптів. У тих же RedHat системах можна записати команди завантаження модуля прямо в " / etc / rc.d / rc.local " з усіма опціями.

Файли конфігурація модулів знаходиться в каталозі " / etc / modprobe.d / " і мають розширення « conf ». У цих файлах переважно перераховуються альтернативні імена модулів, їх параметри, що застосовуються при їх завантаженні, а так само чорні списки, заборонені для завантаження. Наприклад, щоб вищезгаданий модуль відразу завантажувався з опцією « nohwcrypt = 1 » потрібно створити файл, в якому записати рядок:

options rt73usb nohwcrypt = 1

Чорний список модулів зберігається переважно у файлі " / etc / modules.d / blacklist.conf " у форматі « blacklist <ім'я модуля> ». Використовується ця функція для заборони завантаження глючних чи конфліктних модулів.

Перегляд загальної інформації про ядро (версії, імені ОС, апаратна платформа тощо) проводиться за допомогою команди uname.

Переглянути список підключених модулів в даний момент можливо за допомогою тієї ж команди lsmod:

Print-server:/tmp/123# lsmod

Module Size Used by

ipv6 235396 10

loop 12748 0

parport_pc 22500 0

parport 31084 1 parport_pc

snd_pcm 62660 0

snd_timer 17800 1 snd_pcm

snd 45636 2 snd_pcm,snd_timer

soundcore 6368 1 snd

snd_page_alloc 7816 1 snd_pcm

psmouse 32336 0

serio_raw 4740 0

pcspkr 2432 0

i2c_piix4 7216 0

i2c_core 19828 1 i2c_piix4

У наведеному прикладі видно, що в системі завантажено безліч модулів. Більшість з них поставляються разом з ядром і мають вільну ліцензію. Бувають так само модулі та пропрієтарні (наприклад драйвера відеоадаптерів NVIDIA). Відповідно, модульний підхід дозволяє включати в ядро невільні компоненти, якщо пропріентарна ліцензія дозволяє це, що позбавляє від необхідності отримувати дані модулі від виробника заліза.

У прикладі також можна бачити, що відповідними модулями здійснюється підтримка таких пристроїв як відео, SATA, SCSI, дискети та звукові карти, а також мережеві пристрої, наприклад, IPV6, підтримка файлових систем, такий як ext3, і Remote Procedure Call (RPC) компанії Sun.

Окрім імені модуля, команда lsmod показує також розмір, число користувачів модуля і імена користувачів.

Команда modinfo видає інформацію про один або декількох модулях.

Завантажувані модулі ядра мають ряд фундаментальних відмінностей від елементів, інтегрованих безпосередньо в ядро, а також від звичайних програм. Звичайна програма містить головну процедуру (main) на відміну від завантаження модуля, що містить функції входу і виходу (у версії 2.6 ці функції можна іменувати як завгодно). Функція входу викликається, коли модуль завантажується в ядро, а функція виходу - відповідно при вивантаженні з ядра. Оскільки функції входу і виходу є користувацькими, для вказівки призначення цих функцій використовуються макроси module_init і module_exit. Завантажуваний модуль містить також набір обов'язкових та додаткових макросів. Вони визначають тип ліцензії, автора і опис модуля, а також інші параметри.

Завантажуваний модуль являє собою просто спеціальний об'єктний файл у форматі ELF (Executable and Linkable Format). Зазвичай об'єктні файли обробляються компоновщиком, який дозволяє символи і формує виконуваний файл. Однак у зв'язку з тим, що завантажуваний модуль не може дозволити символи до завантаження в ядро, він залишається ELF - об'єктом. Для роботи з завантажуваними модулями можна використовувати стандартні засоби роботи з об'єктними файлами (які у версії 2.6 мають суфікс. Ko, від kernel object). Наприклад, якщо вивести інформацію про модуль утилітою objdump, ви виявите декілька звичних розділів, в тому числі. Text (інструкції),

Data (ініціалізовані дані) і. Bss (Block Started Symbol або неініціалізовані дані).

У модулі також виявляться додаткові розділи, відповідальні за підтримку його динамічної поведінки. Розділ. Init.text містить код module_init, а розділ. Exit.text - код module_exit code. Розділ. Modinfo містить тексти макросів, що вказують тип ліцензії, автора, опис і т. д.

Процес завантаження модуля починається у просторі користувача з команди insmod (вставити модуль). Команда insmod визначає модуль для завантаження і виконує системний виклик рівня користувача init_module для початку процесу завантаження. Команда insmod для ядра версії 2.6 стала надзвичайно простий (70 рядків коду) за рахунок перенесення частини роботи в ядро. Команда insmod не виконує ніяких дій по вирішенню символів (разом з командою kerneld), а просто копіює двійковий код модуля в ядро за допомогою функції init_module ; інше робить саме ядро.

Функція init_module працює на рівні системних викликів і викликає функцію ядра sys_init_module. Це основна функція для завантаження модуля, що звертається до кількох інших функцій для вирішення спеціальних завдань. Аналогічним чином команда rmmod виконує системний виклик функції delete_module, яка звертається в ядро з викликом sys_delete_module для видалення модуля з ядра.

Під час завантаження і вивантаження модуля підсистема модулів підтримує простий набір змінних стану для позначення статусу модуля. При завантаженні модуля він має статус MODULE_STATE_COMING. Якщо модуль завантажений і доступний, його статус - MODULE_STATE_LIVE. Якщо модуль вивантажений - MODULE_STATE_GOING.

При виклику функції ядра sys_init_module спочатку виконується перевірка того, чи має викликає відповідні дозволи (за допомогою функції capable). Потім викликається функція load_module, яка виконує механічну роботу з розміщення модуля в ядрі і виробляє необхідні операції (я незабаром розповім про це). Функція load_module повертає посилання, яка вказує на тільки що завантажений модуль. Потім він вноситься в двусвязний список всіх модулів в системі, і всі потоки, які очікують зміни стану модуля, повідомляються за допомогою спеціального списку. Наприкінці викликається функція init () і статус модуля оновлюється, щоб вказати, що він завантажений і доступний.

Внутрішні процеси завантаження модуля являють собою аналіз і управління модулями ELF. Функція load_module (яка знаходиться в. / Linux / kernel / module.c) починає з виділення блоку тимчасової пам'яті для зберігання всього модуля ELF. Потім модуль ELF зчитується з користувальницького простору в тимчасову пам'ять за допомогою copy_from_user. Будучи об'єктом ELF, цей файл має дуже специфічну структуру, яка легко піддається аналізу та перевірці.

Наступним кроком є ряд " санітарних перевірок " завантаженого образу (чи є ELF - файл допустимим ? Чи відповідає він поточній архітектурі? І так далі). Після того як перевірка пройдена, образ ELF аналізується і створюється набір допоміжних змінних для заголовка кожного розділу, щоб полегшити подальший доступ до них. Оскільки базовий адресу об'єктного файлу ELF дорівнює 0 (до переміщення), ці змінні включають відповідні зміщення в блок тимчасової пам'яті. Під час створення допоміжних змінних також перевіряються заголовки розділів ELF, щоб переконатися, що завантажуваний модуль коректний.

Додаткові параметри модуля, якщо вони є, завантажуються з користувальницького простору в інший виділений блок пам'яті ядра (крок 4), і статус модуля оновлюється, щоб позначити, що він завантажений (MODULE_STATE_COMING). Якщо необхідні дані для процесорів (згідно з результатами перевірки заголовків розділів), для них виділяється окремий блок.

У попередніх кроках розділи модуля завантажувалися в пам'ять ядра (тимчасову), і було відомо, які з них використовуються постійно, а які можуть бути видалені. На наступному кроці (7) для модуля в пам'яті виділяється остаточне розташування, і в нього переміщуються необхідні розділи (позначені в заголовках SHF_ALLOC або розташовані в пам'яті під час виконання). Потім проводиться додаткове виділення пам'яті розміру, необхідного для необхідних розділів модуля. Виробляється прохід по всіх розділах в тимчасовому блоці ELF,, і ті з них, які необхідні для виконання, копіюються в новий блок. Потім йдуть деякі службові процедури. Також відбувається вирішення символів, як розташованих в ядрі (включених в образ ядра при компіляції), так і тимчасових (експортованих з інших модулів).

Потім проводиться прохід по залишених розділах і виконуються переміщення. Цей крок залежить від архітектури і відповідно ґрунтується на допоміжних функціях, визначених для даної архітектури (. / Linux / arch / <arch> / kernel / module.c). Наприкінці очищається кеш інструкцій (оскільки використовувалися тимчасові розділи. Text), виконується ще кілька службових процедур (очищення пам'яті тимчасового модуля, настройка sysfs) і, в підсумку, модуль повертає load_module.