Завантажувальні сервіси - Структура бази даних гендлів

Я згадував, шо працюю зараз над імплементацією UEFI  десь так зсередини, тобто я не став вчити спочатку глибочезний апаратний низ якоїсь платформи і, відповідно, - писати такий собі Start.asm (це теж буде, а якже, але пізніше); я сів вчити саму UEFI, читати її специфікацію, і по ходу діла, бачачи, шо тут можна шось писати, почав це робити. Спочатку думав робити це у вигляді C-побідного псевдокоду, але потім виявилось, шо в принципі нічого не заважає намагатися робити повну імплементацію окремих принаймні функцій. Отже, "ядро" UEFI організоване в сервіси - набір функцій, які обслуговують різну функціональність - API, тільки прив'язується клієнт до нього не через статичне чи динамічне лінкування, а через таблицю диспетчеризації, яку ядро надає кожному завантаженому клієнтові. Це драйвери, застосунки, завантажувачі ОС (теж застосунки). Сервіси суть розбиті на дві категорії - Boot Services, базові сервіси доступні в т.зв. "передзавантажувальному" середовищі (pre-boot environment), тобто власне - в час роботи самої UEFI, і Runtime Services - сервіси часу виконання - виконання ОС мається на увазі, тобто це служби, які ОС може в себе викликати, якшо хоче. Вони доступні і під час передзавантажувального періоду, і після перехоплення контролю ОС, і ОС має розуміти і поважати їхню наявність, шоб могти ними користуватися.
Я, читаючи специфікацію, і дійшовши до детального опису завантажувальних сервісів (ЗС), а це глава 6-та в специфікації, вирішив засісти за імплементацію сервісів обслуговування протоколів, СОП, (Protocol Handler Sevices). Всі ЗС діляться на підкатегорії:

• Event and Timer Services - сервіси подій і таймерів 
• Task Priority Level Services - сервіси синхронізації за рівнем пріоритету завдання
• Memory Services - сервіси пам'яти (інтерфейс аллокатора пам'яти) 
• Protocol Handler Services - сервіси  обслуговування протоколів
• Image Services - сервіси завантажувача образів
• Miscelaneous Services - різне, наприклад сервіс підрахунку Crc32

З евентами, синхронізацією і тим паче - керуванням пам'яттю все дуже не ясно покишо, тож я засів за СОП (сервіси обслуговування протоколів). От про структури даних, повязані з цими сервісами я сьогодні і розкажу. Як я їх вирішув побудувати.
Ці структури даних організовуються в базу даних гендлів (Handle Data Base). Відповідно існує структура, яка цю базу описує. Це такий собі корінь. Уся база організована з структур двох типів, один з яких, - розбивається на 2 підтипи. Отже які об'єкти складають наші дані в роботі з СОП? Це гендли й протоколи. А також - агенти, які є набором гендлів з атрибутами. Інші об'єкти, які можуть використовуватися, але суть з інших категорій, такі як події і таймери, будуть розглянуті в своїх темах, а те, шо стосується їхнього використання в обслуговуванні протоколів, буде додано пізніше, бо як я вже сказав - синхронізація ще не розроблена взагалі. Я не описуватиму, шо значить кожна сутність визначена в UEFI, це треба читати специфікацію, я ж намагаюсь розказувати за імплементацію. Отже гендл це обєкт, який асоціюється з пристроєм, з образом (драйвера, застосунку або самого UEFI), - це персоналізація базового структруного елементу фірмварі. Протокол - це набір з імени і структури, яка містить вказівники на функції і дані, які цей протокол імплементує. Ім'я робиться у вигляді GUID'а.
Цікавий момент з протоколами полягає в тому, шо ідентифікуються вони саме за іменем, а от інтерфейс може бути різним, або взагалі не бути. Протоколи інсталюються на гендл, і там вони існують. Є функції які можуть переінсталювати той самий протокол помінявши в ньому вказівник на інтерфейс, конткретно, - це сервіс ReinstallProtocolInterface(). З цього й видно - шо хоч і здається, шо конткретний протокол має бути прив'язаний до конктретного його наповнення (інтерфейсної структури, - функцій, які він надає), це не зовсім так, і в системі можуть існувати два (або більше) гендли, на яких інстальовано той самий протокол, але інтерфейсні вказівники - різні. Але, з іншого боку, для системи - це один і той самий протокол. Це видно з опису певних функцій СОП. Наприклад функція LocateHandle() або LocateHandleBuffer(), якшо тип пошуку задано ByProtoocol, має просто вернути масив усіх гендлів "на яких інстальовано цей протокол". А протокол задається лише GUID'ом.
Отже ми маємо гендли. Сам тип, визначений специфікацією, - EFI_HANDLE, визначений як VOID * не зобов'язаний бути вказівником на шось. Тобто його значення має "непрозору" (opaque) семантику. Якась прив'язка цього значення до внутрішньої імплементації, вирішується самою імплементацією. І я вирішив використовувати для значення гендла адресу на структуру, яка його представляє. Це дає велику оптимізацію. Бо пошук гендла стає константним по часу - незалежним від кількости гендлів в системі. Ми просто приводимо гендл до типу вказівника на структуру гендла, і якшо треба, читаємо поле валідности - це дає ґарантію, шо ми не поліземо писати в незрозуміло яку ділянку памяти, і далі вже працюємо з гендловою структурою. Не треба нічого шукати взагалі. З іншого боку, адреси - унікальні, тож якшо ми маємо два гендли з різним значенням, вони представляють два різні гендли. І навпаки - два гендли з одним і тим значенням - це той самий гендл. Це оптимальне рішення звичайно має свою ціну - а саме - ми маємо фраґментацію таблиці гендлів. Гендли організовані в таблицю. Це просто масив структур. Висока локальність, без надмірности зберігання вказівників (як в списках чи деревах).  Це перший підтип табличних структур нашої бази. І лише гендли так організовані. Ця таблиця може бути фрагментована, оскільки раз виділивши гендл десь в таблиці, ми не можемо пересовувати його деінде доки він валідний. Це таблиця з непересувними елементами. Дефраґментація відбувається тільки на додаванні - ми вставляємо новий гендл не в край, а спочатку дивимося чи є дірки, якшо є, вставляємо в першу від початку, і тільки якшо нема дірок, вставляємо в край.
Другий табличний тип - це нефраґментовані таблиці. Елементи в них можуть бути пересунуті на видаленні (дивись нижче), тим самим просто підтримуючи протяжність таблиці. В такі таблиці організовані протоколи інстальовані на гендл, і таблиці агентів, які споживають конкретний протокол на конкретному гендлі. Спочатку я думав мати там списки, двонаправлені, закільцьовані, але прийшов до висновку, шо краще динамічні масиви. Знову - масиви дають максимальну локальність і займають менше місця. Вони лінійні по пошуку. Але тут питання кількости. Треба розуміти - ми маємо таблицю гендлів, на кожному гендлі інстальовано протоколи, і кожен протокол має скількись агентів, які його споживають. Просто неймовірно, шоб оці дві останні таблиці були довгими. Важко сказати, нажаль, це не легко оцінити, але, з іншого боку, очевидно - це не може бути великим числом. Тобто питання кількох одиниць на таблицю. Уявляєте якою надмірністю тут було б використовувати дерева! І з огляду на масштабованість - так само неймовірно, шо з часом ця кількість збільшиться, просто по суті - тут не може бути великої кількости елементів. Ну і якшо вже буде - тоді переробимо на дерева.
Як робитиметься дефраґментація. На видаленні якогось елемента (аґента чи протокола), функція, поміщатиме на його місце крайній елемент в списку. Спочатку здавалось, шо дефраґментація буде складним завданням і дорогою операцією. Потім прийшла здогадка про оцю релокацію на видаленні. Таблиця увесь час протяжна. І це досягається за константний час. Ми маємо індекс на перше вільне місце в струткурі, яка має цей масив. Наприклад в гендлі, ми маємо поле NumberOfProtocolInterfaces - це і кількість протоколів інстальованих на цьому гендлі, й індекс першої вільної клітини в масиві. Завдяки цьому полю ми маємо доступ до останнього елемнта константно. І таким чином можемо робити константне переміщення для дефраґментації. Ясно, шо якшо елемент, який видаляється останній, переміщення немає. Нажаль з причин уже вказаних вище, ми не можемо так робити з таблицею гендлів. Але там ми маємо константний доступ, а тут лінійний. Просто лінійність тут не буде повільною - ми маємо невелику кількість елементів. Надто невелику, шоб будувати тут дерева.
І третій тип в нашій базі. Це допоміжна структура. Це словник протоколів в системі. Як вже було відзначено, семантика протоколів взагалі робить їх більше приватними для гендла, згадайте хоча б свободу реінсталювати на протоколі інтерфейсний вказівник, - це має приватний обшир для конкретного гендла. З іншого боку, ми маємо кілька сервісних функцій, сенс яких аж вимагає мати системний словник для протоклів - адже попри волю в виборі інтерфейсу, протокол для системи - це його GUID і всі протоколи інстальовані на різних гендлах з одиним і тим же GUID'ом є одним і тим же протоколом. Саме для оптимізації пошуку за протоколом, ми вводимо третю допоміжну структуру - словник протоколів. Такі функції як LocateHandle() і LocateHandleBuffer(), якшо параметр пошуку є ByProtocol, а також LocateProtocol(), вони мають ключем пошуку саме протокол (його GUID). Очевидно якшо ми шукатимемо через таблицю гендлів, а потім через масив протоколів в кожному гендлі, ми матимемо жахливу залежність O(N*m') - де
N - це кількість гендлів системі (в таблиці), m' - це середня кілкість протоколів в таблиці протоколів кожного гендла. Інші ж функції, а саме ProtocolsPerHandle() , або вищезгадані перші дві, якшо параметр пошуку - AllHandles, виграють сильно в своїх операціях від використання таблиці гендлів. Адже без пошуку вони вже мають гендл, а потім просто видають список протоколів інстальвоаних на гендл, або видають всі гендли в системі - це лінійна робота за будь якої структури організації. Саме набір семантики оцих сервісів і диктував вибір організації підлеглої бази даних. Варто коротко нагадати які саме пошукові сервіси задані UEFI:

• Група яка має ключем протокол
• Група яка має ключем гендл

 Перша група, це функції, які як пошуковий ключ отримують протокол і видають гендл(и), на якому (яких) цей протокол інстальований.
Це такі функції:

• LocateHandle() , LocateHandleBuffer() за пошукового параметра ByProtocol - видають всі гендли які мають цей протокол інстальований
  
• LocateProtocol() - видає перший гендл на якому цей протокол інстальований

Друга група, отримує гендл як ключ (або директиву обійти всі гендли):

• ProtocolsPerHandle() - видає всі протоколи інстальовані на гендлі
• LocateHandle(), LocateHandleBuffer() за пошукового параметру AllHandles - видають всі гендли в системі

Саме через наявність отієї першої групи, з'явилась ідея додати третю допоміжну структуру - словник протоколів. Я не знаю, яка кількість протоколів в системі буде, але очевидно - це більше, ніж число протоколів інстальоване на конкретному гендлі. І того було вирішено зробити цей словник у вигляді червоно-чорного двійкового дерева пошуку. Пошук логаритмічний, локальність не дуже, але це як завсіди - баланс. Червоно-чорні дерева з точки зору операцій пошуку, суть такі самі як звичайні двійкові дерева. Отже зараз, коли ми поки не чіпаємо інсталяцію/деінсталяцію, можемо лише сказати, - словник протоколів, введений для пришвидшення пошуку на сервісах, які беруть протокол як пошуковий ключ. Це перша група сервісів. Це дублювання не складає ніяких проблем для цих пошукових сервісів, вони ці структури не будують, а лише читають. Але й сервіси, які будують, про які я розкажу наступного разу, вони навряд зустрінуть тут велику складність маючи необхідність додатково в добре визначених місцях алгоритму обслуговувати ще й дерево на додачу до таблиць. А виграш очевидний. В нашому дереві, кожен вузол - це протокол, і він має масив гендлів (саме гендлів а не структур гендлів як в таблиці гендлів). Цей масив будується як нефраґментована таблиця. І вона так само очікується вельми коротка. Отже порівнюючи. Наші сервіси першої групи за відсутністю допоміжного дерева мали б час пошуку O(N * m'), а з деревом матимуть O(n' * logM), де як уже казано:
N - число гендлів в системі,
m' - середнє число протоколів на гендлі
n' - середнє число гендлів на протоколі
M - число протоколів в системі
Очевидно, очікується, шо n' - буде вельми малим, - це кількість гендлів, на яких цей протокол інстальований. Багато протоколів будуть інстальовані взагалі на одному гендлі; ну а M у нас уже під логаритмом. Погодьтесь, різниця є.
Отже підсумовуючи. Структура БД вибрана з огляду на семантику сервісів, які в свою чергу вибрані такими, творцями специфікації з огляду на зручність їхнього використання в клієнтах. БД організована як таблиця гендлів, яка є фрагментований (можливо) динамічний масив. Кожен гендл має таблицю протоколів, які на ньому інстальовані - це нефрагментований масив. І кожен протокол має таблицю агентів, які його споживають на цьому гендлі - ця таблиця теж нефрагментована. Дефрагментація досягається переміщенням крайнього елементу на видаленні як згадано вище. Фрагментованість таблиці гендлів іде як ціна від прискорення через використання адреси структури гендла як його значення, для його ідентифікації. Але фрагментованість очікується низька. До того ж система всеодно має можливість дефраґментувати таблицю на вставленнях.
Нарешті, для прискорення пошукових сервісів, які мають як ключ пошуку протокол, вводиться допоміжна структура - словник протоколів в системі, імплементований як двійкове червоно-чорне дерево пошуку, з високими показниками ефективности пошуку.
Пізніше я додам іллюстрацію, а в наступній статті, проаналізую функції додавання/видалення на описаних структурах, які відбуваються на сервісах інсталяції/деінсталяції гендлів/протоколів/агентів.
Така ось крива й коса ілюстрація бази даних гендлів. може колись я навчусь краще робити ілюстрації, а покишо ось:

UEFI - вступ

Боже, як швидко летить час. Більше року тому я почав тут писати за проєкт. Шо ж, мої невидимі читачі, я хочу вас запевнити, - я не закинув нічого, просто от так швидко летить час. Не виправдовуючись, можна тільки сказати - проєкт складний, він потребує багато навчання, багато роботи, за навчання не дуже роскажеш, ну читаєш ти, ну учиш, і шо, кому це цікаво. І тим паче це не "документування" процесу створення ОС. І все ж, відчуттям, здавалось пройшло ну місяців, ну хай 8, але ж не 14! А я ж думав писати сюди десь принаймні допис в місяць. Але є як є. Час летить, і я постійно нию за це...
Залишивши лірічний відступ, шо я хочу сьогодні розказати. Мабуть варто описати поточний стан речей коротко. Це ж таки щоденник, який відображає історію. Нажаль, я поки шо не розібрався зі структурою цього документування, того хай поки це буде пласка череда дописів. Така стадія, шо нема перед очима структури, я ж не книжку пишу.
Отже, я зупинився в самому кінці попереднього допису на згадці "вивчання старту на армі". Саме вивчення таких речей привело мене до ідеї, яка тепер уже є реальністю в цій роботі. Я не знаю чи мав я тоді її, коли писав попередній допис, але зараз маю.
Коли вивчаєш старт платформи, ти неминуче пересікаєшся з концепціями ROM-коду і фірмварі. Вивчаючи за останню, ти бачиш, наскільки вона схожа з ОС в своїх потребах, цілях, внутрішній будові і інструментах - вона фактично робить те саме (і так само), шо й ОС, тільки в міні-варіанті, - забезпечує підтримку машини, поки ОС не перебере контроль на себе. І далі ти взнаєш, як тобі не подобаєтья у-бут, який так тісно запиляний на лінукс, який такий такий, шо тобі він не подобається загалом. А саме він робить вигляд фірмварі на платах, які ти вибрав як першу хвилю на твій проєкт. До речі за це. З часу минулого допису, я надбав ще дві машини - armv8 rk3368 восьмиядерний OTT коробок з відроїдом - це 64-бітний арм, таки маю його. це я купив в серпні. І, о диво, я таки отримав Mips Creator CI20! І отримав в прямому сенсі, оскільки Imagination так і не продає в Україну, я б не міг його купити і досі. Мені його просто подарували. Просто так, і безплатно доставили (при чому з третього разу - попередні довізники морочили голову і повертали назад). І зробила цей шляхетний крок одна добра людина з Imagination - Alex Voica. Безмежна вдячність йому за цей безпрецендентний своєю бескорисливістю чин і постійні безперервні промені добра в його бік. :) Ця подія заслуговує на окремий допис. Десь в майбутніх "спогадах". Отже тепер я маю такі цільові машини для проєкту:
Beagle Bone Black, TI Sitara AM3358, Cortex-A8, armv7.
Cubieboard 2, Allwinner A20, Cortex-A7, armv7.
Mips Creator CI20, Ingenic JZ4780, XBurst2 (?), mips32r2.
CSA-90 OTT Box, Rockchip RK3368, Cortex-A53, armv8.
iMac g5, ppc64.
і x86 новт.
Історично, я завсіди хотів починати з міпса. Але не міг його знайти. І переключився на арм. Але міпс таки прийшов до мене, і так, "перша хвиля" була визначена. З певним відривом в ній іде сьомий арм, оскільки я вже заглибився в непролазні нетрі його специфікацій від арма. Але й підтримка міпса планується іти паралельно, як же я можу не починати з міпса маючи його зараз на руках, навіть коли я збирався починати з нього не маючи його! Я вже казав, шо через його непагану документованість і однопроцесорність, BBB взято як найпершу машину. А Cubieboard і CI20 ідуть одразу за ним. Це перша хвиля.
Повертаючись до фірмварей. Я вирішив написати свою фірмварю в рамках оцього початкового кроку до ОС. І нехай не здаватиметься, шо головним мотиватором було моє незадоволення у-бутом, насправді я мало знаю за нього, те, шо знаю, мені не подобається, але це все, це просто моя суб*єктивна думка, вона не є визначальною в цьому рішенні. Просто вона вдало поєднується з рештою контексту. Мені всеодно треба вміти "піднімати" машину на рівні фірмварі, розуміти деталі на цьому ж рівні, і треба вчитися в цьому ж середовищі, руслі. Я б міг починати з завантажувача ОС на пристойній фірмварі, але хіба це багато міняє? Навпаки, написавши фірмварю, я не тільки впевнюсь, шо я можу писати ОС, не тільки набуду неоціненного досвіду, але ще й матиму корисне на виході для інших. Я передивлявся за різні фірмварі і не міг не помітити UEFI. А дивився за OpenFirmware, дивився за ARC, і UEFI. І якшо на x86 полі UEFI підтримується зараз нормально, і було б логічно саме починати з UEFI OSLoader'а для твоєї ОС, так само - з завантажувача ОС на OpenFirmware-ному iMac'у, то, на цих міні-PC машинах з моєї першої хвилі, ти не маєш нічого такого пристойного. То чого б не спробувати в рамках твого проєкту принести це туди, з усіх отих вищезагаданих причин-мотивацій? Сама UEFI не запиляна під сервери, як хтось може подумати, і може добре служити на мобільному, вбудованому й інших сегментах, просто її ніхто не приніс туди. От це звичайно мотивує. І скажіть, шо це заважатиме ОС проєкту, авжеж ні! Це грандіозний крок вперед і перевірка себе, а заодно пристойна фірмваря для міні-PC користувачів. З усіма її смаколиками. Які саме вони, мабуть не треба тут писати, ті хто зацікавлені будуть це читати, напевно мають своє сформоване уявлення шодо UEFI. А я розказуючи за мою роботу над нею, розказуватиму і про неї, і по ходу це відкриватиме й її вигоди. Я давно знав, шо моя ОС використовуватиме ACPI, було б дивно не заангажувати сюди й UEFI - ці стандарти створені один для одного. Буквально. Восьмий арм, він наче як збирається мати UEFI підтримку, але ті, хто там крутить те все, здається вирішили, шо воно тільки йтиме на їхній і досі тільки мітичний серверний напрямок. А того всі оці ОТТ коробки і розробницькі ОПК з "малими" 53-ми кортексами, випадають з їхнього, тих чуваків, огляду. Вони думають за UEFI на восьмому армі тільки в контексті серверного майбутнього. Міпс взагалі не має UEFI. А це ще більше мотивує. І так от я й вирішив імплементувати UEFI на кілька машин з сьомим армом, восьмим, і міпсом, покишо тільки 32-бітним, бо 64-бітного на горизонті поки не має. Чого "кілька"? Бо це ж фірмваря. Залежність імплементації від платформи ще більша, ніж в "низів" ОС. Але цей підпроєкт, може жити окремим життям в разі успіху, і якшо хтось доєднається, діапазон підтримки може розширитися. Початково ж, я вирішив писати UEFI на БББ і CI20 (ну важко весь час перемикати розкладку). До речі, шоб не писати весь час модельні імена і їхні малозрозумілі скорочення, та ще й в різних абетках, я, згадуючи тут окремі цільові машини, далі називатиму їх за іменем, яке я їм дав. Бо це зручно. А зацікавлений читач легко засвоє це. Та й машин не густо. xD Отже BBB машину я назвав "муран" - на честь собаки (насправді двох) з села.) Ясно, адже емблема BBB - бігль, собака. Свій Cubieboard 2 назвав аргоном, не знаю чого, я хімік, от чого. Ci20 - йодом, - те саме, шо з аргоном. Плюс ci20 - фіолеотовий (пурпуровий), йод теж фіолетовий, і грецьке слово яке дало ім*я йоду, "йодес", означає "фіолетовий". CSA90 OTT коробок я назвав чортиком - через намальованого на коробоку зеленого андроїда-відроїда, а айМак назвав "блондином". xD Здогадайтесь чого!)

Продвинутий, серйозний читач, збайдужіло і роздратовано читаючи попередній абзац за імена, скаже тут - UEFI не декларує підтримки міпса! Це так, але це не проблема. Наш little endian-ний ci20 (Йод) легко може бути туди втесаний - нема технічних перешкод. Сформульовані для включених архітектур вимоги чітко показують, шо визначити за аналогією таке саме для міпса не є проблемою. Я маю на увазі, шо міпс архітектура, не має ніяких внутрішніх властивостей, які б завадили сформулювати за аналогєю з вже підтриманими архітектурами, вимоги і для неї. Ну а далі, нічого не заважає цій майбутній імплементації запалити інтерес власників стандарту вставити підтримку в специфікацію. :)
Тож, надалі якийсь час тут можна очікувати балакання переважно за UEFI. Оскільки це іще й окремий проєкт, то, можливо, він також і окремо буде висвітлений.
Ідучи далі, щодо роботи з "старту платформи". Всеодно і в UEFI, виділяється такий собі низ - це стартовий код, ініціалізація з боку заліза, це дуже специфічні для платформи речі і асемблер того процесора, який ти програмуєш.  Це всюди однаково. І якшо ОС вже прийматиме контроль через встановлений UEFI інтерфейс і зроблену її UEFI-завантажувачем роботу, то це просто переносить найнижньорівневіший код в UEFI, ОС стартуватиме більш стандартно визначено. Всеодно, це тільки про старт, а повна підтримка машини? Отже, - HAL і драйвери від лазіння в специфіку апаратури не втечуть. Бажаючи набути досвіду, мені взагалі не варто тікати від важкої роботи з самого початку, якою ініціаліація апаратури безумовно є. Тож мій вибір логічний і узгоджується з моїм баченням, шо я маю робити, шоб "зробити" те, шо хочу. На платформах з цільових машин, які мають UEFI чи OF, можна буде починати з завантажувача ОС, клієнта відповідної фірмварі. Не варто й казати як досвід імплементування самої UEFI допомагатиме тут. Отже це буде корисно на всіх цільових платформах, а не тільки на цільових для UEFI-імплементації платформах - власне більшість з них стане уефішними платофрмами, а це - добре визначений інтерфейс для ОС на більшости її цілей. Це полегшує розробку самої ОС. І нарешті ще раз - користувачі матимуть добрерозроблений промисловий стандарт замість тієї самодіяльної хаотичної каші. В ідеалі, вони зможуть мастурбувати з своїми лінуксовими компіляціями набагато інтенсивніше з UEFI фірмварним інтерфейсом - грузитимуться і з флешки і з USB жорсткого диску, і з мережі, і з будь якої незліченної GPT партиції! І навіть з сексі диску! xD (SCSI диску, я читаю цю абревіатуру саме так, і це до речі - саме так, як один з розробників того стандарту пропонував її читати офіційно, пуританство решти завадило мабуть, але взятий варіант "сказі" має для україномовного користувача не вельми приємні коннотації. "Сексі" ж рулєз для всіх, чи не так? Отже, наскільки я не знайомий натепер з сексі стандартом, і в руках не тримав, і в очі не бачив, настільки я вже впевнено знаю, шо називатиму його саме так). Ці вищезгадані можливості треба ще імплементувати. Але в UEFI, ти маєш грубезний довідник стандарт, який чітко і детально каже тобі, шо ти маєш зробити і як воно все пов'язано. Плюс я належу до людей, які вірять, шо така продумана (спеціалістами з досвідом) впорядкованість дає добрі плоди, якшо ти стаєш на її ґрунт. А у-бут - це антипод цього. Де там до речі документація на нього? Ні, не рецепт, як мені "сконпілірувать" їхню фігню, а те, як воно влаштоване, які його ідеї, принципи, концепції й інші фільозофічні речі, яких вони дотримуються? Отож.
Чи багато я зараз знаю за UEFI? Ну не мало. Чи багато ще взнавати? О так! Чи багато я написав КОДУ? Мало. Але я вже не просто базікаю і мрію. Я вже роблю. І звичайно, ця писанина призвана в тому числі бути звітом за результати роботи. Отже маючи успіхи, я обов'язково напишу про них тут.  А зараз я прийшов розказати про поточний напрямок роботи. Задокументувати еволюцію.

вступ 1

в цьому продовженні вступу, вирішив написати трохи про user space'ну частину моєї планованої системи (далі просто - системи, або ОС, або ant , ну тобто, я не робитиму постійно уточнень шодо її планованого статусу, її ненаявности чи неповноти).
це цікаве питання, бо якшо навіть відкинути весь скептицизм шодо можливости написати систему одному чи просто - скептицизм шодо саме моїх можливостей, то всеодно, постає резонне питання: ну гаразд, а які застосування твоя система ганятиме? ти намагатимешся склонувати WinApi в усій його повноті шоб мати можливість виконувати весь той космос Windows'івських програм, як це намагаються робити певні проєкти, чи ти може надумав свій api замутити і, як наслідок, тобі треба тоді ще й весь користувацький простір наповнювати... або створювати екосистему, загукувати так би мовити розробників з усіх країв писати їхні проги під твою ось.
звичайно, шо ні. я не такий наївний, може й наївний, але не настільки. шодо другого варіанту, тобто "свого" api для юзер простору, - це одразу очевидно нереалістичний варіант - жодна найталановитіша й найпрацьовитіша людина не напише ядро і всі системні бібліотеки і всі найпотрібніші юзерські прогамні набори (наскільки талановитий і працьовитий є я, залишимо на осуд майбутнім користувачам). а головне, це не є необхідне шоб дати своїй системі якесь використання. і про це трохи далі. шо ж до першого варіанту, тобто відтворення WinApi, то тут відповідь дешо інша, але в головному - та сама: це нереально і я не маю навіть такого наміру. бо навідміну від тих, хто намагається там "конкурувати" і бути "альтернативою", це просто смішно, я просто люблю Windows, і не хочу нічого конкурувати чи ще шось. я намагаюсь відтворити в своїй системі ті концепції NT, бо мені це просто цікаво. того я не маю жодних релігійних настроїв робити клона на рівні api в тому числі, з практичної ж точки зору - це й нереально.і все просто - то дуже великий і складний набір. але, в своїх планах я маю намір імплементувати певне так би мовити базове ядро WinApi. і це, звичайно робиться, бо цей інтерфейс є для мене звичним, правильним і таким шо логічно вписуватиметься в загальну картину. а оскільки це буде лише базова підмножина, то й імплементувати його буде реалістичніше.
тут я підходю до основної теми цього параграфу (чи як його назвати). це стосується концепції NT, так званих підсистем середовища. саме за допомогою широкої підтримки цієї концепції, я намагатимусь рішити проблему нестачі застосунків для моєї системи.
зараз це бачиться так. буде одна обов'язкова юзерспейсна підсистема (підсистема середовища далі буде скорочено ПС), ця базова ПС, за замовчуванням так би мовити (Default subsystem, dss), вона якраз і базуватиметься на тій базовій підмножині з WinApi про яку я згадував раніше. вона буде доступна завсіди, і всім програмам з різних ПС. за її допомогою планується написати наприклад базовий набір системних утиліт, які формально не будучи частиною ОС, все ж будучи дуже потрібними, будуть частиною дистрибуції. тобто йтимуть як інтегральна частина релізу. це не native api, тобто ntdll, ця, логічно є на рівень нижче. дефолтна підсистема це мій мінімалістчний внесок в юзерспейс. бо я концентруюся на створення ядра.
а от решта, решта це будуть вже наявні, тобто імплементовані інтерфейси, і програми під них. виникає питання: які саме такі інтерфейси наявні, шо вони можуть стати в цій архітектурі повноцінними ПС? ну, читач який розуміє про шо тут ідеться, вже давно здогадався - мова йде про posix. адже імплементації саме цього інтерфейсу є в активному обігу. тобто кажучи коротоко, в користувацькому просторі, я вирішив покластися на posix, шоб спростити собі завдання зробити систему якою ще люди зможуть користуватися ща признеченням. хоч як мій віндовс орієнтований погляд дивиться на цей посикс, але саме він є в доступі, так, шо я можу його адаптувати і відкрити для своєї системи чималий простір програм написаних під нього. відкривши таким чином свою систему користувачам.
тепер, замість створення api, його імплементації, і написання кожної програми під потреби користувача, мені треба "втесати" наявну імплемегтацію posix в рамки ПС моєї системи і втесати - означає серед іншого, зробити так, шоб посиксні програми могли вільно виконуватися на твоїй системі. який це рівень сумісности? рівень вихідних кодів чи може бінарний? :) звичайно перше скоріше, про ефективне підганяння під чиєсь abi, з усіма місцевими фокусами і містикою - це нереалістично. хоча було б цікаво, наприклад зробити можливість пользунам ганяти на системі одразу їхні бінарні програми з лінукса якого небудь. нативно і без компіляції. зараз це бачиться як занадто складне. шо планується як реалістично складне - це брати якусь bsd-ліцензовану libc з компанією, і на їхній базі, вносячи потрібні зміни створювати реалізацію посиксної підсистеми на твою ОС. а далі, вже буде видно чи вимагатимуть окремі програми - я маю на увазі користувацькі програми запиляні під посикс - буде видно чи вимагатимуть вони і як багато якшо так, змін в вихідних кодах. але це реалістичніше за бінарну сумісніть. звичайно, не все буде гладко, бо посикс хоч і мав на меті яку таку портованість, навряд він цього досяг, існує купа несумісностей. ну і знову посикс покриває далеко не все. от я наприклад не уявляю поки, наскільки складно було б перенести під мій посикс такий програмний комплекс як Xorg.
до речі кажучи за графіку. це одна з причин чого я бачу повне відтворення віндовсівського юзерського апі нереалістичним. графіка це дуже цікава штука, це цілий свій космос. але в тому то й справа, шо навіть на рівні елементарної графічної системи це вже непосильний труд якшо ти не концентруєшся тільки на ньому. не кажучи вже про всі ці 3D речі чи відео кодеки. того, наприклад, мені думається, шо я навряд зміг би навіть gdi відтворити. тож, з графікою в мене туго. і покишо моя система - це текстовоорієнтований командний інтерфейс. одним словом - канцоль. :D якшо це все виходитиме, то графіку додаватимуть зацікавлені учасники. кажучи за яких, згадується питання ліцензування. тут нічого ще я не знаю, але шодо посиксної ПС можна сказати - оскільки, як я зазначив я братиму це від інших і воно буде bsd-ліцензоване, то, ясно, шо таким буде і моя посиксна ПС. я не належу до порушників опортуністів.))) ну і тут же проглядається ще дещо - так я не в захваті від gpl, того й балакаю за bsd'шну версію як вибір попри меншу поширеність і, як наслідок, можливу розвиненість, можливо. але вся ця квазірелігійна волокіта мене не цікавить взагалі і мені не хочеться тут це піднімати. я згадав за це для повноти опису, оскільки наче як це було треба уточнити.
отже от це мої думки з приводу частини користувацького простору. є ще сесійний менеджер, і багато чого іншого. сьогодні я торкнувся саме теми ПС. а покишо я намагаюсь розгребтися з стартом в сьомому армі, з безпечним режимом і небезпечним режимом :D вивчаю інструменти, і покишо це ще тільки зародок завантажувача в планах.))) ще ніпрошо писати. але, сподіваюсь діло йтиме як треба. :)

вступ 0

вирішив зробити блог (нічого не знаючи за це), шоб писати сюди свої думки, міркування, описувати процес, робити хроніку, створення, якшо получиться, :D свого проєкту. проєкту зі створення операційної системи загального призначення, базованої на концепціях і ідеології Windows NT. типу щоденника розробника, звітів там про те як же воно робиться і шо получається, а шо ні. шоб це було доступно не лише мені, раптом з цього шось вийде і це ще комусь буде цікаво. навіть якшо нікому не буде цікаво, то принаймні я матиму інтернет бекап цієї історії.
зараз ще мало можна сказати за цей проєкт. та й допис цей більше пробний - просто шоб побачити як воно робе. бо в принципі писати на планшеті блог - незручно. і це дуже м'яко кажучи! зараз вдома нема інтернету окрім як на планшеті. але головне - системи ще нема! :D така невеличка малість. того ну шо можна сказати на цьому початку. лише коротко про плани. це робота для себе для душі. не для заробляння. просто дуже цікаво. дуже сильний виклик. і насправді серед купи можливих напрямків, спеціалізацій оце - створення операційної системи - на вершині інтересів, найпривабливіше для мене. оскільки це проєкт на роки і надскладний, тут багато чого ще навіть не усвідомлено, багато чого не визначено і з визначеного може багато разів мінятися. тож треба мати на увазі.
шо визначено. вибрані архітектури процесорів на які буде цілитися система. вибрані саме вони переважно з міркувань їхньої релевантности для сучасного користування. тобто ті які вживаються розвиваються і ті з них, які доступні мати собі вдома розробницьку машину шоб це все робилося практично а не тільки мріялося. отже того маємо x86, 32 і 64 бітні варіанти, armv7 з перспективою розширення до armv8, mips 32 і 64 бітні, і ppc, теж 32 і 64 бітні. дуже б хотілося мати можливість спробувати себе на itanium. але, зрозуміло, доступність майже нульова, і гірше - загрозлива перспектива припинення розвитку процесора. тож відкладається на майбутнє, хоча мабуть найпривабливіша цільова архітектура для мене. також sparc. але те саме - доступність не дозволяє. решта цікавих архітектур випадає просто бо їх позакривали. alpha наприклад. дуже цікаво але вже історія.
з згаданих архітектур я маю кілька машин доступних мені на x86, маю навіть тільки 32 бітний четвертий пентіум з 2004 року. для ppc маю старенький iMac g5 з PowerPC 975FX, невпевнений щодо правильности номера моделі але це неважливо, теж 2004 року, одноядерний, зато 64 бітний. шось новіше і багатоядерне розглядаю як розробницьку ціль але це на майбутнє, шось накшталт Mikrotik RouterBoard 850Gx2, знову ж, невпевнений шо модельний номер правильний, планшет не комп, і 3g інтернет не найкращий спосіб діставати всю інфу під руку, ось пишу по памяті і точні цифри моделей можу плутати. там, в роутерборді двоядерний qoriq наче як на 1 ГГц від freescale (це, звичайно, я розмріявся, - частота - 500MHz, ось дивився сьогодні). але цього зараз не маю. ну а з армівської сім'ї маю два рішення -  розробницькі плати у вигляді mini PC, одноядерний SoC з Cortex-A8 в beaglebone black, і Cortex-A7 двоядерний в Cubieboard 2. AM3358 і A20 від TI і Allwinner відповідно. тобто є однопроцесорне і двопроцесорне рішення, к'юбіборд по конфігурації дуже нагадує ту яка всередині планшета на якому пишу (якшо звичайно знехтувати різницею між 7мим і 9тим кортексами). ну і нарешті mips. не знаю чого але дуже цікава мені архітектура, непагано було б саме з неї почати. але нажаль на неї не маю жодної машини. і грошей не маю))) Imagination, власник міпс архітектури, випустив цікаву плату mips creator ci20, з двоядерним mips32 процесором всередині сока. ось на це й цілю. все добре, крім того шо не доставляють вони в Україну це диво інженерної мислі британських вчених і майстерности китайських виробників. покишо. і їхнє soon, виглядає дуже непереконливо. не знаю чи взагалі доставлятимуть. тож з міпсом покишо лишається теоретизувати. але оскільки це просто колосальна робота і може навіть і непосильна для 1єї людини, починати треба з чогось одного, попри переносність в дизайні, практична імплементація всеодно йтиме поштучно. тож почни а там побачиш шо ти можеш. роботи вистачить. почати я рішив таким чином з арма. хоча вже казав чогось особливо хотів би з міпса. отже з арма, з одноядерного варіанта, без smp , шо логічно, цільова платформа - beaglebone black.
ось і шоб нотувати процес, шоб воно відобразилося в історії, хай навіть для себе, рішив, шо крім строгого документування треба вести типу шось як щоденник. а потім подумалося шо і блогувати було б непагано. було б шо. саме для цього я прийшов сюди і саме для цього почав цей блог. сподіваюсь далі буде.