Перейти до вмісту

"Мій нікому нецікавий блоґ" або записки за UEFI.

GPT UEFI FAT

Повідомлень в темі: 131

#81 _Ex

    STATUS_OK

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 1629 повідомлень
  • Стать:Чоловік
  • Місто:Бахмут, Південна Слобожанщина, Україна

Відправлено 31.03.2017 – 15:35

Якшо наша ОС буде, вона довго буде TUI - Text User Interface системою, як на Avril так і на PussyX ПС. Отже одними з перших застосунків для нашої системи мають бути оболонки, командні інтерпретатори. Для обох ПС (cmd.exe і sh.exe відповідно). А також - підлегла нижньорівнева "консольна підсистема" - аналог графічної підсистеми, на GUI платформах (Graphical User Interface).
Запишу трохи ідей про т.зв. командне зв'язування. Оболонка виконує свої "програми", задані як послідовність операцій (statements), складених з виразів, складених з операторів і операндів. Задані чи то у ввідний потік чи в якийсь файл. Між іншим там існують команди, як оператори. мабуть. :lol: Загалом ім'я команди - це просто ім'я якоїсь програми, і воно може бути задане як повний або відносний файловий шлях в фс ієрархії, де ця програма лежить. Але необов'язково це має бути лише це. Кожне програмне середовище, середовищна підсистема точніше, надає набір "стандартних" команд, які користувач очікує, шо вони завсіди наявні на цій системі. насправді в POSIX - це частина стандрату і ідеї, навколо він крутиться - ґарантувати такий набір. шоб дрокати в кансолі, дрокати дрокати. Також інсують просто "дефакто" стандратні команди - численні системні утиліти. В будь якому випадку, вони або специфікацією або традицією тісно інтегровані в саме середовище.
Розгляньмо таку ситуацію. Існує команда A, яка робе шось важливе але доволі просте. І робе це швидко. Якшо ми просто напишемо консольну програму з іменем A, і покладемо її десь, де правила пошуку виконуваних файлів для оболонки дозволять її знайти, то ми можемо легко її використовувати як частину мови оболонки, тепер "A" це команда оболонки, яка буде виконана, якшо ви наберете її ім'я в оболонці:
C:\Users\Ivan>A [Enter]
C:\Users\Ivan>A
Usage: A [option 1 [option 2=valueAczSaaz], ... , option100500]
Як це робитиме внутрі? Оболонка розбираючи свої стейтменти, знайде цю команду, і потім після пошуків її виконуваного модуля і перевірок, запустить окремий процес A.exe.
Саме про це хотілось сказати. Створення окремого процесу і мання окремої програми для кожної найменшої команди - це зайва морока тут. Надзвичано неефективне і марнотратне рішення. Того шо існують значно ефективніші шляхи виконати цю команду. Наприклад набором робочих потоків оболонки. Отже команди мають бути вбудованими. Але механізм вбудовування має бути динамічний і розширюваний. Для цього потрібне командне зв'язування. Це покишо лише ідея, того уйма деталей просто відсутня. І неможна сказати, шо вони не вплинуть на подальший рух ідеї. Просто якось же треба розробляти це. Ідея така. Командне зв'язування вставаляється в закон пошуку оболонкою виконуваного модуля для команди. Десь, де це не суперечить стандарту чи логіці. Коротко, - стає частиною змінної PATH, для ясности. Але замість пошуку виконуваних модулів і запуску процесів для них, оболонка підтримує свій простір імен команд і на старті з нього будує свою ефективну таблицю пошуку вбудованих команд. І в тій таблиці відбувається прив'язування імени команди до сутности, яка її виконає. І сутність ця буде не цілий процес і окрема програма для нього, а експортована функція з бібліотеки, яка зареєструвала цю команду в просторі імен оболонки. А виконуватиметься вона в контексті робочого потоку оболонки. Шоб не конфліктувати з фс пошуком довільного виконуваного файлу як команди, цей простір імен лежатиме в реєстрі.
Загалом, більшість команд буде висажена в корінь цього простору імен. Це даватиме можливість запускати команду просто по імені, але якшо виникають колізії імен, у реєстратора команди всеодно є можливість зареєструвати цю команду з тим самим іменем, але він має покласти її в дочірній вузол простору імен. і викликати вже як \ns1\cmdname, де ns1 - це ім'я дочірнього вузла в корені ПІ оболонки.
З таким підходом ми маємо значно зменшити оверхед виконання команд, і, також, уникнути надзвичайно подразливого і тупого дублювання і копіювання функціональних ресурсів. Як? дивіться. окрім згаданих "стандартних" і "добре відомих" "малих" команд, є ще один клас, на іншому краю. Це інтерпретатори, інтерактивні мови, скриптові мови. Тут ми маємо дворівневу оболонку - спочатку ви запускаєте в оболонці який небудь python, а потім він приймає свої команди, свою мову, скрипти зазвичай. Тобто якшо у випадку простих команд, ми маємо одну бібілотеку і купу команд, які кожна сама по собі, тут ми маємо складний двигун інтерактивної скриптової мови, і лише одну команду для оболонки - python, perl, rexx, php, jscript, vbcript, fsharp. будь шо. Ми хочемо вбудувати і цих монстрів в оболонку. Як це зробити, шоб не дублювати той самий python по сотнях папок, коли кожна програма, яка залежить від нього абсолютно бездумно приносе свою копію цього пітона. Ми маємо інсталювати його на машину правильно® - шоб усі інші компоненти могли бачити його присутність. Версіонування теж має бути враховане - шоб на системі був лише мінімальний потрібний набір версій конкретної шняги.
Шоб наша оболонка могла вбудувати цю бібліотеку, все шо буде треба від її постачальника - це надати експортовану функцію, яка служитиме як вхідна функція для цієї команди. Очевидно, шо команда тут завсіди одна, наприклад - "python". Далі то вже його робота. Хоча обмежень на кількість команд/експортованих фукцій, ясно нема.
Приклад.
\shell
.\shellext	---> $PATH$	---> %SYSROOT%\utils.dll C:\Programs\Something\else.dll C:\Programs\Rexx\rexx.dll
				 ---> arp	---> __CmdArp
				 ---> ping
				 ---> rexx	---> RexxEntry

..\ns1		---> $PATH$	---> C:\Users\prog\commands.dll
				 ---> rexx
реєстровий ключ "shellext" служить коренем командного простору імен оболонки. Всі його підключі, - це вузли ПІ, де можна класти команди, які конфліктуватимуть з іншими командами кореню будь вони покладені туди.
Кожен вузол, і корінь теж, має величину $PATH$, яка перелічує імена бібліотек (не директорії), суб'єкти для пошуку символів відображених в цей вузол ПІ. Решта величин задає відображення імени команди на ім'я експортованого символу. Імя величини - це ім'я команди, Значення цієї величини, якшо присутнє, - це ім'я експортованого символа з якоїсь з бібліотек, заданих в величині $PATH$ (вони не конфілктують за визначенням, бо реєстрація додасть нову бібліотеку в вузол лише якшо нема колізій). Якшо значення відсутнє, значить ім'я команди і символа збігаються.
Будування цієї таблиці відбувається лише раз на старті, і нічого не заважає оболонці зберігати принаймні частково скомпільовану таблицю в той же реєстр, моніторячи дату на цьому ключеві і ключеві кеша, і лише в разі "зачерствілости" кеша перекомпільовувати його.
Також це дає можливість мати по-користувацький набір команд для оболонки. B) І кожен користувач може легко побачити усі команди, які йому доступні (і хто насправді їх надає), глянувши в цей ключ.
  • 0

#82 _Ex

    STATUS_OK

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 1629 повідомлень
  • Стать:Чоловік
  • Місто:Бахмут, Південна Слобожанщина, Україна

Відправлено 31.03.2017 – 20:33

^ можна звичайно обмежитися лише змінними $PATH$ в кожному вузлі, тоді всі експортовані функції бібліотек стають командами, й імена їхні визначатимуться іменами функцій. Це швидше, але тоді бібліотека зав'язується на оболонку, виникає проблема дублювання. Хоча, звичайно, зараз важко сказати чи це проблема (не дублювання, а те, шо якась бібліотека має бути обережною з своїм експортом, якшо хоче бути розширенням оболонки), також як - чи є проблемою задавати відображення імен на функції.

Повідомлення відредагував _Ex: 31.03.2017 – 20:35

  • 0

#83 _Ex

    STATUS_OK

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 1629 повідомлень
  • Стать:Чоловік
  • Місто:Бахмут, Південна Слобожанщина, Україна

Відправлено 12.04.2017 – 01:01

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

Після ініціалізації Hal, і компонентів Ex, яка покишо заглушкова - туди додаватиметься, покишо це просто визначений порядок, в якому компоненти ініціалізуватимуться, наша система має породити три потоки - Idle потік, цей буде створений власне самою ініціалізаційною послідовністю - тобто цей початковий бутовий потік, стане ідлом для бутстрапового процесора.
Два інших потоки - це Console SS потік і Cmd потік (чи Shell потік) будуть породжені в кінці ініціалізації. Серед інших цілей, ця трійця - перший полігон для тестування диспетчера (планувальника). Зображення
Idle - він і в Африці ідл. Нічогонеробіння потік. В найпростішому варіанті, на йоді, виконуватиме інструкцію wait. В подальших, розробленіших версіях, - смикатиме різні павирсейвинг фічі. Але за це ще рано. Вейт сам по собі теж нічого собі сейвинг, шоб ви знали.

Console SS - потік консольної підсистеми, зародок процесу, який системно обслуговуватиме кансоль® або як нам наравицця це називати - TUI - text user interface, ще кажуть CUI - console user interface, ну куй це якось цейво, най буде туй.
Цей потік створюватиме і обслуговуватиме абстракції ConIn, ConOut (вони ж - StdIn, StdOut, stdin, stdout, stderr), тобто обслуговуватиме В/В для своїх клієнтів - консольних програм, які можуть нічого не знати, крім C-шних функцій В/В. Я поки не знаю - чим вони мають бути ці стандартні штуки, типу як "файлами", коротше буферами в пам'яті, хитро представленими як якісь файли, куди консольні програми пишуть і звідки читають.
Сам він, консолесс, концептуально і з оглядом на майбутнє, буде наче як єдина GUI програма розгорнута в повноекранний режим (пізніше, коли стане окремим процесом), з головною віконною функцією, віконною процедурою, сповіщеннями (messages) від ядерного графічно-текстового двигуна (avrilk.sys). Майже як в Віндових віконних програмах, але значно простіше. Набір месаг буде лише той, шо треба для малювання текстІв на дисплей (ConOut), і обробки тицькань клавітаури. Пізніше - миші також (ConIn). Але з введенням все дуже сильно запущено - для цього нам потрібен USB стек. Нема його поки. Ingenic jz4780 насправді має контроллера для PS/2 клавіатури чи миші, але на йоді це не використовується, не виведені ці піни нікуди, нема відповідних портів на платі, отже тіке USB HID миші і клави. Шо з функціональної т.з. зовсім непагано. Але є одна дрібниця - потрібен робочий USB стек.
Тобто назараз - це потоки, які виконуються в ядрі, але потім будуть винесені в свої користувацькі процеси.
консольний потік відповідатиме за малювання тексту, курсор, обслуговування буферів В/В, направлення В/В. Тобто його клієнт просто викликає функцію напр printf("Hello, world!\n"); і все. А на дисплеї з'являється текст. От консольний потік намалює це. Просячи це зробити графічного двигуна через його сервіси. За нього нижче.

Cmd потік. Зародок командного інтерпретатора. Він використовувтиме лише стандартні функції В/В. Єдиний покишо клієнт згаданого вище консольного потока. Це розбиття на клієнта і сервер, зроблено, шоб одразу ліпити правильно обидві моделі - консольних програм, які нічого не знають про малювання, і - відповідної підсистеми, яка має знати все за те малювання, адже навіть в текстовому режиі треба малювати на дисплей. Нема VGA з текстовим режимом тут.
Наш командний потік служитиме інтерфейсом з нами, але лише коли з'явиться введення. Спочатку саме виведення, яке робитиметься якимсь спрощеним варіантом printf(). :cool2:

Тепер за дрова. Імена їхні концептуальні, для наочности. Може вони такими й лишаться, а може трохи зміняться.
Я так подумав, наші стартові потуги мають бути розтроєні в три потоки. Core - це зародок ядра, диспетчера, менеджерів, Hal, - це те, про шо ми одразу думаємо, коли балакаємо за стартовий код в ядрі, початки тобто, не з бутової т.з.
Але також, з самого початку важливі ще дві периферійні речі, дуже важливі - це вже зачеплений трохи користувацький інтерфейс, серед якого дисплей грає центральну роль. І - постійне сховище. Треба одразу братися за це і робити його як треба. Наприклад, можна було б спочатку для збергіання використовувати дуже примітивне поблокове В/В; діставшись до потрібних регістрів, такі костилі було б можна замутити. Класти і витягати потрібні дані з фіксованих позицій внутрі сховища, лізучи туди лише знаючи LBA, блокові адреси. Але це можна дозволити лише з SEC фазою, там це просто вимога ром-коду, він хоче лише голий бінарник з сигнатурою на секторі 1. Далі такі танці не годяться. Бо це не буде і близько те, шо очікує користувач. Користувач очікує файловоорієнтоване постійне сховище. І наше ядро - це теж такий користувач. Або наприклад, уявімо, ми вперше змогли намалювати на екран, пройшовши всі дєбрі LCD, HDMI і решту ахтунгів. Це ж історичний момент! Його треба запічатлити. :D Можна звичайно сфотографувати на камеру телефона чи планшета. Але зняти скриншот - краще! Ок, скриншот в bmp-форматі готовий, шо далі? Правильно, його треба кудись зберегти, кудись в постійне, нелетке сховище. Підтримки мережі нема, передавати ~ 2 MB корцінку через UART, я навіть не впевний як це зробити, з нашою конфігурацією ці два метри байтів просто виваляться в вікно програми, яка обслуговує це термінальне з'єднання (PuTTY). Ні, звичайно треба писати наш історичний скриншот в файл і класти його в постійне сховище. А його треба підтримувати ще.
Отже крім ядерного напрямку початкового коду, ми маємо, дисплейний і сховищний.
Ото внизу в коричневих прямокутниках намальоване відповідне залізо. HDMI і LCD - це відповідні контроллери, які керують, керуватимуть, нашим hdmi монітором. Чесно, я ще не докумекав як LCD в'яжеться з HDMI. Але суть така, - спочатку іде LCD, а потім його виходи ідуть до HDMI. На мурані, там є такий hdmi-фреймер, такий гладкий чип, розміром майже з чип SoC'а, тобто це зовнішній до сока контроллер, в соку сидять два LCD контроллери, які "думають", шо вони водять LCD-панель, а насправді ці виходи заходять в hdmi-фреймер, і він транслює ці сигнали в hdmi-відповідники. Тобто це класичний міст. Сам він сидить на SMBus шині (I2C), тож якось трохи зрозуміло. А тут, за LCD понаписано багато, а за HDMI ніхрєна. Хоча, очевидно, відповідна логіка сидить десь в соку, нема тут зовнішнього hdmi-водія. Коротше, я ще не знаю, хто керує hdmi-портом, хто є останній в цій заплутаній черзі керівників, сигнали від якого ідуть нарешті в монітор. Того ми там намалювали два драйвери - hdmi.sys і lcd.sys - міні-порти, функціональні драйвери відповідних інтерфейсів, вони зрештою займатимуться програмуванням відповідного залізяччя.
А от X2D - це така індженикова фігня, вона означає eXtreme 2D, ну ви поняли, це той самий "акциліратор" 2D графіки, звичний "екстрим" в назві, натякає на його крутизну в цьому, - пришвидченні плаского малювання, десктопу, всього за винятком 3D ігрової фігні. Він начебто описаний, але якось паршиво. Шо ж, ми всеодно маємо надію його використовувати. Власне він має ефективно робити графічні завдання, трансформації принаймні якісь. Ще цікавить совання цих бітових карт пікселів канешно. За нього я шось не бачив, але має таке бути. Мініпортовий драйвер x2dminip.sys возитиметься з регістрами цього девайса. На прохання графічного двигуна, avrilk.sys, пам'ятаєте, я вже згадував його, і казав, шо між іншим, він буде хостом для графічної справи. це наш аналог віндового win32k.sys. Цей драйвер має вигадати набір графічних сервісів, і осблуговувати їх за принципом - взнати чи є на системі "акциліратори" для відповідних завдань. Якшо є, зв'язатися з ними і проштвхувати зрозумілою їм мовою ці завдання. Нема таких? Значить робити це самому, використовуючи центральний процес. Просто? Хоч би за півроку хоч хрому версію цієї простоти написати. Навіть для однієї лише TUI. Знову варто наголосити - на нижньому рівні це всеодно малювання попіксельно, тут нема VGA, який надає спеціально програмований, виділений текстовий режим. Також наша аврилка має надавати горішній інтерфейс для клієнтів. А це, правильно, - консольний потік згаданий вище. Пізніше - консольна підсистема. І також, вона має створити оте середовище, в якому літають UI месаги, вона має створити відповідні об'єкти (і типи для них спочатку), і має створити чергу повідомлень, і постити туди повідомлення для консольного потоку. Який їх оброблятиме в своїй віконній процедурі, в міру прилітання. Знову - викликаючи сервіси ядерної підсистеми, аврилки тобто. Вся оця дуже непроста UI фігня.
Колись, коли система стане графічною, клієнтів стане більше, ніж один, їх стане багато і складність завдань зросте. А покишо, консольна підсистема - єдиний клієнт, і вона малює все для доволі тупих, зізнаймося, в плані інтерфейсу, консольних програм.

Тепер за постійне сховище. У нас є два підтипи його. Колись додадуться старі добрі жорсткі диски. З сатою і ахці. А покишо у нас є два NAND-базовані підтипи. Один це SD і eMMC інтерфейси і картки/модулі, вони мають всередині контроллери, які скривають нанд структуру і виставляють свою SD/eMMC структуру, яка має дуже звичний блоково-орієнтований вигляд. Також контроль за зношенням нанд клітин вони беруть на себе. вони роблять ремапинг паганих блоків, вони розносять писальне навантаження рівномірно (ми, користувачі, так сподіваємось). Тобто до певної міри цей підтип простіший.
Другий підтип - це голий нанд. Всі обов'язки з керуванням паганими блоками, і правильним писанням в цей примхливий пристрій сховища, лягають на хостове софтваре, тобто на ОС.
Для обох підтипів потрібні нижньорівневі функціональні драйвери. Я вже казав, на нашій платформі і нанд і сд/ммц контроллери неперелічувані, вони не сидять на якійсь шині, яка б їх організовано і стандартно перелічувала. Тож ми їх перелічуватимемо, за допомогою інфи, записаної про них десь в ACPI таблицях, і Hal, розбираючи ті таблиці, стане енумератором, шинним драйвером для цих пристроїв. Через нього робитиметься павир-мениджьминт цих пристроїв. А от функціоанльна їхня частина потребує окремої підтримки. Концептуально ми це зобразили двома драйверами - nand.sys і sdio.sys. На йоді нема eMMC. Хоч SoC і може це. Ці драйвери знатимуть як написати в ці пристрої і як прочитати з них. Вони нічого не знатимуть про абстрактніші але теж, цілком реальні (і такі ж важливі) речі, як партиції, томи, файлові системи. Вони надаватимуть відповідні IRP функції (читально-писальні), вони постачатимуть ISR'и/DPC (обробка відповідних переривань), там де це аплікабле як то кажуть.
Партиціями займатиметься драйвер трохи вище в відповідному стеку, partmgr.sys - менеджер партицій. Його "пристрої" - це MBR, GPT або якась кустарна таблиця партиціонування (дивись за нанд нижче). На основі цієї інформації, він створюватиме об'єкти для вищих драйверів, і ці об'єкти представлятимуть "диски", насправді партиції - вмістилища для ФС (файлових систем).
З першим підтипом (а також звичайними жорсткими дисками), тут простіше - ми маємо або MBR схему, або GPT, цієї різниці не існує для ФС, її обслуговує менеджер партицій. Тут все так просто, бо для звичайних блокових пристроїв, дійсно партиція це такий самий масив послідовних блоків, як і весь фізичний пристрій сховища. І ці схеми розбивання (зроблені для зручности) добре туди лягають, не дивно, вони для таких сховищ і вигадані. Єдина різниця між фіз. диском і його партицією, натуральна - не можна вважати дві партиції одного фіз. диску чимсь 100% паралельним. По доступу наприклад. Все ж вони сидять на одному диску. Але от дві партиції з різних фіз. дисків і два ці диски ніяк крім розміру не відрізняються. Того наприклад, файлова систмеа цілком справедливо думає лише за свої партиції, як за цілком незалежні диски. В т.ч. і з т.з адресації - вона все рахує відносно партиції, тому, менеджер партицій додає потрібний офсет партиції відносно цілого фіз. диску шоб дати нижньому драйверу його адресу.

Цього неможна сказати за другий підтип - голий нанд. З кількох причин. Одна з них, і це більше не через примхливу природу нанду хоч як дивно, а через вимоги ром-коду. Він накладає доволі непродумані вимоги до своїх навантажень, і як наслідок непродуманости, - добряче похерює дружбу з багатьма стандартами. Так він відсікає можливість використовувати GPT схему. Бо він вимагає своє навантаження (нашу ФВ) сидіти саме починаючи з сектору 1, дуже дуже пагано - GPT хоче там свій хедер, і це несумісно. Тобто на SD-картках - лише MBR. Але на нанд він накладає ще більше вимог, які відкидають і MBR. Він хоче, шоб там лежала купа маркерів, довжелезна, з добрячою надмірністю, яка б казала йому за тип нанду.
Але, і сам нанд - це не зовсім блоковий пристрій. Це пристрій, який має одні одиниці для писання нулів і зовсім інші - для скидання всього в одиниці. Він має сторінки і блоки відповідно. Перша операція - зміна з еразе-стану (початкового стану) в протилежний - це програмування нанду, і воно робиться посторінково. Сторінки різні на різних нандах, на йодовому - 8 КБ наприклад (не рахуючи "зайву" площу, spare area). Друга операція, з страхітливою назвою, еразе, erase, - це скидання бітів в клітинах в початковий стан, еразе-стан. На нандах, я, так розумію, це стан, який трактується як одиниця в біті. ця операція робиться на зовсім інших шматках, на еразе-блоках, і вони значно більші за сторінки. Наприклад на йодовому - це 1 МБ, тобто по 128 сторінок. І воно це еразе робиться за раз. Це архітектурна штука. Щойно блок вернувся в еразе стан, - він пройшов один П/Е цикл. програм-еразе цикл. Нажаль, флешові клітини з кожним П/Е циклом зазнають незворотніх змін, деградують, зношуються, аж сльози на очі накочуються. Достатньо одному біту деградувати до стану, який не повертає впевнено визначений (записаний туди) рівень (0 або 1), все, цей блок викреслюється з використання, він втрачений навсігда. Очевидно - інтенсивне писання в одне й те саме місце, якраз і роблять це П/Е навантаження, яке вбиває нандові клітини, псуючи одразу цілі блоки. Потрібна стратегія проти зношування, wear leveling називається, розгрузка зношування.
Так просто пройшовши по натурі нанду одразу й не допетраєш, а шо ж там не так, шо ускладнює звичайне партиціонування, звичайні його схеми? Є дещо. По-перше ром-код, він нікуди не дінеться, і якшо ти збираєшся класти свою ФВ на нанд, а це ж і є головне постійне сховище, то, MBR і GPT відпадають. Цього вже досить. Але є і те, шо вимоглива природа нанду вимагає особливого підходу. Тобто принаймні треба врахувати, шо терти багато разів цю ділянку не можна. Полетить перший блок, шо тоді робити? Ясно, шо класти якісь копії в один і той же блок безглуздо, резервувати кілька МБ блоків для структури на сотню байтів - це вже занадто. Того, найімовірніше потрібна своя кустарна схема партиціонування. В якій наприклад резервується 2-4 блоки (2-4 МБ на йоді), і туди іде кустарна таблиця партицій і ФВ, у вигляді майже непереписуваних FV - ФВ томів, це виправдовує використання місця. Вся решта займається партиціями з спеціальними, зробленими для нанду ФС.
І якшо на першому типі, ФС вільно пише в партицію, менеджер якої налаштовує адреси відносно фіз. диску, тут, на нанді, хто зна, чи має це сенс, чи є тут така можливість. Прикол в тому, шо спеціальні нанд флеш ФС мають бути більш аваре про підлеглу структуру пристрою. А може й не мають. Шо вони точно мають, так це дбати за зношування. Як виявиться далі, це не обов'язково вимагає від такої ФС контролювати весь нанд пристрій і адресувати його "прямо".
На першому типі, і спершу, ми плануємо імплементувати FAT ФС. Вона відносно проста. Пам'ятаєте, в нашому розробницькому середовищі, SD картка довго гратиме роль основного сховища. Залишається сподіватися, внутрішній контроллер подбає за протидію зношуванню. Зрештою, сімейство FAT ФС - це задекларовані стандартом ФС типи для SD карток. Мають подбати. Ані FAT, ані яка інша hdd орієнтована ФС нічого не знає за протидію зношуванню.
На другому типі, ми спочатку думали за exFAT, все ж, вона схожа з першою, вона крута і всі діла, вона наче б то аваре за нанд флеш природу. Але вона патентовано-незадокументована. Пригадуються слова класика - "отака гуня, малята".
Тож, ми "псіхонули" :D і вирішили імплементувати YAFFS2 ФС. Отако. Головне для нас в ній - вона нанд дружня і не патентована. Хоча й документація теж не дуже є. Як завсіди для опин-шмопин проєктів. "Читай код, лузер" - ось документація. Ну суть трохи pdf файлів, і на тому дяка. Невідомо чи самому прийдеться писати, чи таки взяти і переробити наявну їхню імпементацію, тут в другому варіанті спливає така дратівлива фігня як GPL. Але зараз не за це.
Дружність цієї ФС до нанду, чим ми заклопотані насправді, полягає не в тому, шо ця ФС спеціально імплементує продію зношуванню, на шо спочатку ти й розраховував, ну логічно ж. Але от виявляється існує такий підхід в організації ФС, який дає ту протидію як сторонню фічу. Хоча власне ця властивість іде сама по собі, а не заради wear leveling'а. Це ж треба таке! Ці ФС називаються ФС журнального типу, і особливість їхня полягає в тому, шо вони завсіди пишуть послідовно, вони кладуть сутності в сховище одне за одним, постійно пишучи в вільне місце, в край вже написаного, ніколи не лізучи назад, всередину, доки не дійдуть справді краю сховища. Тобто пишуть як в журнал - записати можна в край, а не десь, де вже записано. Згадайте, одиниці писання (програмування) в нанді - сторінки, одиниці витирання все на початковий стан, еразування - блоки. От такі журнальні ФС пишуть в сторінку, яка поточна в блоку, перша вільна, яка має еразе-стан. Змінюєш ти файл, і замість того, шоб перетерти відповідну сторінку, де цей шматок файла лежав, ФС просто пише новий вміст в вільний край блока - в першу вільну сторінку. А та попередня, стає невалідна, черства чишо. От так сторінка за сторінкою повзуть дані, щойно весь блок містить лише черстві дані, тоді і лише тоді, він одразу увесь зазнає еразування, цілком звичайно, воно тіке так і можливо - поблоково, і тіке тоді він знову вільний і готовий до нового використання. Журнальні ФС трактують сховище як циркулярний, замкнений журнал. Ти пишеш в вільний край, дійшовши до справжнього краю пристрою, вертаєшся на початок, де вже готові нові еразовані блоки. Подумайте, в цій поведінці закладена "дружність" до нанду, протидія зношуванню. Сама собою така поведінка розподіляє писання рівномірно між блоками. А я й не знав. А якже в такій системі зв'язати вміст файлів? Папки всі, як воно робе? Звичайно, потрібно зв'язування, воно є. І потрібні чималі допоміжні леткі структури в пам'яті для обслуговування цього. Ну але все має свою ціну. А для чого власне RAM, "оперативна" пам'ять, як не для таких "оперативних" завдань?
Це завдання, імплементція YAFFS буде складніше за FAT. Але лише з ним, ми можемо використовувати NAND. Вдумливий читач може сказати, - "тю, так напиши прошарок між фат-драйвером і нандовим драйвером-писуном, який дбатиме за вер левелинг, відтворюючи аналогічну стратегію, для фата видаючи звичайні сектори". Звичайно це варіант, але чим він простіший?
Вертаючись до партиціонування на нанді, ми підкреслюємо - звичайно воно потрібне. Хоча б через капризні вимоги ром-коду. Було б трохи легше віддати весь чип нашому нанд специфічному ФС драйверу, але це і неможливо і також - відсікає можливість потомового рознесення підсистем середовища, про шо я казав раніше. Обмежує функціональність. І, як бачимо, не особливо потрібне, - YAFFS може оперувати на партиції, всеодно роблячи верлевелинг. Просто постійно супроводжує думка, шо його ефективно можна робити лише маючи на руках увесь пристрій одразу. Ні, з журнальними ФС, це не треба. За винятком якихсь нереальних вироджених випадків, де існуватиме якась мікроскопічна партиція, інтенсивно писана, робота ФС в якій нічого не дасть через брак місця, нормальні сценарії партиціонування не загрожують попсути верлевлинг зроблений ФС. Шо за "нормальний" сценарій і як він реалізовуватиметься, як ґарантуватиметься? Наприклад на йоді, ми маємо 8 ГБ-ний чип. "Нормальним" тут би було зробити 2 "звичайні" YAFFS партиції - по одній на ПС порівну ~4 ГБ. Плюс, - ФВ-ний том, таблиця партиціонування і ром-кодові забаганки в перших (2-4) блоках. Вирішуватиметься і ґарантуватиметься це на часі інсталяції, де інсталятор не дозволить користувачам жартівникам встановити опцію, яка вб'є їхній флеш.
А кустарна схема там буде така ж як GPT, за винятком тих речей, які не можуть бути там через обговорені нюанси. Це бекап копії, захисна МБР мабуть, це вимога класти GPT заголовок в сектор 1. Який сектор, тут нема секторів. Тут сторінки і блоки, шо вважати "секторами"?...
Щож до адресування блоків і сторінок - як ФС має робити - адресувати відносно свого тому (як перший тип), і партиційний менеджер транслюватиме це, чи має робити глобальну адресацію, це ще не вирішено бо не ясно ще багато чого.
Гаразд, не за все я в цій темі розказав, але я вже заморився, я багато розказав. :)
  • 0

#84 Татка

    Частий гість

  • Користувачі
  • PipPipPip
  • 57 повідомлень

Відправлено 12.04.2017 – 15:49

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

Повідомлення відредагував Татка: 12.04.2017 – 15:51

  • 0

#85 _Ex

    STATUS_OK

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 1629 повідомлень
  • Стать:Чоловік
  • Місто:Бахмут, Південна Слобожанщина, Україна

Відправлено 12.04.2017 – 16:05

ну я прочитав. :lol:
насправді, коли я його писав, він не здавався таким довгим. це якийсь візуальний ефект форматування, шо робе його таким дооовгим. :D
  • 0

#86 _Ex

    STATUS_OK

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 1629 повідомлень
  • Стать:Чоловік
  • Місто:Бахмут, Південна Слобожанщина, Україна

Відправлено 12.04.2017 – 20:21

В рамках своїх шукань в ділянці файлових систем, підписався на мейлинг-лист такого динозавра як JFS. Це айбіемівська скам'янілість, яка таке враження ніде крім крепекса не використовується, та й там вона не грає роль першої скрипки (каламаре, яка ФС у вашого лінукса? екстраздватричотири чи МаслоФС?).
Але я колись бачив якийсь бенчмарк, де JFS викурила всю решту крепексових ФС по швидкості. Ну все ж корпоративні дослідження, учоні, не те, шо задротські поробки. :lol: Попри мій природній скептицизм до айбіем (я ж МС фанбой), все ж, я не засліплений фанатик, я впевнений їхня JFS краща за ext чи btrfs. От вона мені й цікава як кандидат на роль "крутої" ФС звичного, ЖД сегменту сховищ, навідміну від згаданого вище нандового підтипу, де, ми казали, ми накинули оком на YAFFS. Як шось замість NTFS, оскільки остання не задокументована (добре) і я не знаю, чи я зможу її коли небудь нопейсати (через згадану незадокументованість і складність). Тож, якшо NTFS не получиться, треба якась схожа "крута" ФС для жоских дисків, з журналом і B+ деревами. :brovy: Я давно думав або за XFS або за JFS на роль плану Б для NTFS.
Підсумовуючи мої сміливі еротичні фантазії в галузі ФС:
1. Перша ФС як базис, як "має бути" - така легка, така універсальна і швидка - сімейка FAT. FAT16 і FAT32. У нас нема флопі-дисків, нема потреби впадати в FAT12.
2. ФС спеціального призначення, для капризних сховищ типу нанд. YAFFS2, описано вище.
3. Нарешті для звичайного ЖД середовища. Мрії - NTFS. JFS або XFS. На колись. Це складна складна штука.

Так от, підписався я значить на той мейлинг-лист, ну я очікував, шо це дуже тихе місце, не очікував бурхливої активности. шукаючи документацію, це добре видно - якісь одиничні записи на sourceforge, від автора ФС з далкого 10-го чи 12-го року. тихе болото. Ясно, ібеме попіарилось на "любові до лінукса" і забуло.
Але, несподівано, сьогодні прийшло аж з десяток "патчів" звідтіля, так, на списках розсилки чогось тепер люблять постити ці дурні патчі з тими дурними diff-вирізками по яких всеодно ж нічого не поймеш. Навіть сам шеф автор ФС вигулькнув. Круто, приємно коли є активність в роботі, а не валяється рокаим закинуте.
Але чого я там ніколи не очікував побачити, так це поштову адресу Мікрософта в одного з учасників. Це було шось таке:
Прихований текст

Я очікував багато мікрософтівців в списку edk, UEFI, вони ж зрештою, одні з засновників того форуму. Вони там є але мало й рідко. Взагалі, на роботі там одні інтелівці (може ще арм і лінаро), всі інші наче як на общєствєних началах (апле, червоний капелюшок, інша дрібнота).
Але де де, а на напівзакинутій ібеемівській ФС для лінукса, я не очікував побачити майкрософтівців. Шо вони там роблять? Вай? Мабуть через ту галіму віртуалізацію, погнало начальство інтенсивно "любити лінукс". В рамках нової усміхненої політики. Та й автор ФС, вже з оракле поштою там. А як же бетерефесе і зефесе? це ж сантехніківські "діаманти". Нашо їм JFS? Чудне.
От напишу фат, почуюсь крутим фс чуваком і піду там базікати з тими крутеликами за файловосистемну жиснь. :lol:
  • 0

#87 kalamar

    Старійшина

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 3989 повідомлень
  • Стать:Чоловік
  • Місто:Чорнильщина

Відправлено 12.04.2017 – 21:29

Перегляд допису_Ex (12.04.2017 – 20:21) писав:

В рамках своїх шукань в ділянці файлових систем, підписався на мейлинг-лист такого динозавра як JFS. Це айбіемівська скам'янілість, яка таке враження ніде крім крепекса не використовується, та й там вона не грає роль першої скрипки (каламаре, яка ФС у вашого лінукса? екстраздватричотири чи МаслоФС?).
Але я колись бачив якийсь бенчмарк, де JFS викурила всю решту крепексових ФС по швидкості. Ну все ж корпоративні дослідження, учоні, не те, шо задротські поробки. :lol: Попри мій природній скептицизм до айбіем (я ж МС фанбой), все ж, я не засліплений фанатик, я впевнений їхня JFS краща за ext чи btrfs.
ext, ext2, ext3, чи ext4. Це принципово різні файлові системи. Тупо порівнювати їх по швидкості сенсу нема. ext/ext2 не журнальні, сумніваюсь, що журнальна jfs2 швидша. Є швидка журнальна ReiserFS, але методи журналювання є різні. Data mode - журналюється і inode і дані, найвища надійність, найнижча швидкість, ordered mode - журналюється тільки inode, але контролюється запис даних, writeback mode - журналюється inode, нема контролю за записом даних. ext4 можна по різному монтувати, по дефолту ordered, можна зробити data, а можна і writeback.
Щодо btrfs то це нова система, copy on write, там принцип не як у класичних журнальних.

Повідомлення відредагував kalamar: 12.04.2017 – 21:41

  • 0

#88 _Ex

    STATUS_OK

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 1629 повідомлень
  • Стать:Чоловік
  • Місто:Бахмут, Південна Слобожанщина, Україна

Відправлено 12.04.2017 – 22:12

Для користувачів це не тупо, швидкість важлива. (це не я порівнював всеодно, шо ви. :lol:). Зрештою, це ФС загального призначення. І я непам'ятаю, можливо там порівнювались лише системи з схожими фічами, тобто ext4-jfs-xfs-reiserfs.
також пам'ятаю, виявилось, шо імплементований через жопу user-space NTFS, всеодно був на порядок швидший XFS. :D
На мою скромну дуже непрофесійну думку, нічого крім метаданих журналювати не варто.
РайзерФС, я колись цікавився цим, в нього їх там дві, і вони різні, 3-я і 4-а, ви яку саме маєте на увазі, мабуть же третю. Бо з четвертою, наскільки я пам'ятаю, його "нипонялі" і не взяли той шедевр. Цікаво, він вже вийшов з в'язниці? Його систему я точно не розглядатиму, він заносчивий занадто. Навіть як для опиншмопин представників.
extN ФС можуть бути цікаві такою стороною як interoperability.
Просто вже якшо вибирати шось з позавіндового простору, то шось гоже. XFS і JFS виглядають найсолідніше. Перша хвалиться підтримкою монстроузних розмірами сутностей. Позабував я вже все, шо читав. Нема нормальної документації на них - оце справжня неприємність. Куди більша за снобістські пшики від тамошніх ораторів.
Гаразд, а ви флеш-носії використовуєте? SSD я маю на увазі. Якшо так, то там чому ви надаєте перевагу як ФС?
  • 0

#89 kalamar

    Старійшина

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 3989 повідомлень
  • Стать:Чоловік
  • Місто:Чорнильщина

Відправлено 12.04.2017 – 23:43

Перегляд допису_Ex (12.04.2017 – 22:12) писав:

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

Перегляд допису_Ex (12.04.2017 – 22:12) писав:

також пам'ятаю, виявилось, шо імплементований через жопу user-space NTFS, всеодно був на порядок швидший XFS. :D
Порядок це в десять разів. А те, що ви пишете то цілковита брехня. Те, що NTFS в лінуксі повільний як черепаха знає кожен дуалбутчик, для того бенчмарків не треба, то неозброєним оком видно при копіюванні файлів.
Тут тести, там кілька сторінок.
Там в одному ntfs виграв, але боюсь то артефакт. :)

Перегляд допису_Ex (12.04.2017 – 22:12) писав:

Гаразд, а ви флеш-носії використовуєте? SSD я маю на увазі. Якшо так, то там чому ви надаєте перевагу як ФС?
Не використовую. Але SSD наскільки розумію має обмежену кількість перезаписів, тож тут, справді є сенс про ext2 подумати, чи мабуть краще ext4 з вимкненим журналюванням. Хоча можливо і нема сенсу паритись, і SSD все дно свій час прослужить. Тобто, тут справді, журналювання зменшує строк служби дивайсу.

Повідомлення відредагував kalamar: 12.04.2017 – 23:45

  • 0

#90 _Ex

    STATUS_OK

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 1629 повідомлень
  • Стать:Чоловік
  • Місто:Бахмут, Південна Слобожанщина, Україна

Відправлено 13.04.2017 – 00:06

о, moronix. :D
Я нажаль не пам'ятаю де я читав ті тести, але пам'ятаю, шо там в коментарях був сам афтар тієї імплементації. "Цілковиту брехню" перенаправляю на нього.) А може XFS ще повільніша на лінуксі? :D Ви ж нею навряд користувалися?

Про вимкнення електрики, гм, ви знаєте, це треба добряче вимкнути електрику, шоб втратити "пару терабайтів даних". я казав про здоровий баланс, між параноєю надійністю і швидкодією, тут він нмд якраз і полягає в журналюванні лише метаданих. за цієї схеми, вимкнення електрики попсує мінімум користувацьких даних в найгіршому випадку. і як можна назвати користувача, який цінні дані зберігає на машині без ДПЖ - джерела постійного живлення? Скнарою чи бовдуром? :D А диски ж іще можуть просто поламатися. То треба вбудувати "снапшоти" в ФС, версіонування!... І в цій гонитві за 100% надійністю, ФС стає монстром, який зжирає всі ресурси, і потужні машини обслуговують лише саму ФС. Наприклад я чув, шо для "нормальної" роботи, тобто забезпечення всіх тих фіч, ZFS вимагає не менше ніж 8 ГБ оперативної пам'яти!
  • 0

#91 kalamar

    Старійшина

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 3989 повідомлень
  • Стать:Чоловік
  • Місто:Чорнильщина

Відправлено 13.04.2017 – 00:23

Перегляд допису_Ex (13.04.2017 – 00:06) писав:

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

Перегляд допису_Ex (13.04.2017 – 00:06) писав:

за цієї схеми, вимкнення електрики попсує мінімум користувацьких даних в найгіршому випадку. і як можна назвати користувача, який цінні дані зберігає на машині без ДПЖ - джерела постійного живлення? Скнарою чи бовдуром? :D А диски ж іще можуть просто поламатися. То треба вбудувати "снапшоти" в ФС, версіонування!... І в цій гонитві за 100% надійністю, ФС стає монстром, який зжирає всі ресурси, і потужні машини обслуговують лише саму ФС. Наприклад я чув, шо для "нормальної" роботи, тобто забезпечення всіх тих фіч, ZFS вимагає не менше ніж 8 ГБ оперативної пам'яти!
В мене летіла fat32 під віндою після вимкнення електрики. Нічого незвичайного тут нема.
Чому ви вирішили, що дані обов’язково цінні мають бути? На кий біс робити бекапи різного роду сміття скачаного з нету? Але коли полетить, все одно неприємно.
  • 0

#92 kalamar

    Старійшина

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 3989 повідомлень
  • Стать:Чоловік
  • Місто:Чорнильщина

Відправлено 13.04.2017 – 02:01

Перегляд допису_Ex (13.04.2017 – 00:06) писав:

о, moronix. :D
Ось від автора тести.
Тобто ext2 була швидша за ext3, але поступається ext4 навіть з журналюванням. Там також видно, який виграш швидкості ви матимете при відключеному журналювання. Виграш не такий вже й великий. Але у випадку ssd, мені здається основне питання не швидкість, а кількість записувань, тому при використанні ssd журналювання мабуть слід вимикати.
Щодо флешок, то їх зазвичай в fat форматують, адже вони для перенесення інформації, а вінда ніц, крім своїх файлових систем, не вміє. :wink2:

Тут почитайте.
журналювання відключати не можна, бо без нього TRIM не працюватиме.

Перегляд допису_Ex (12.04.2017 – 20:21) писав:

Але де де, а на напівзакинутій ібеемівській ФС для лінукса, я не очікував побачити майкрософтівців. Шо вони там роблять? Вай? Мабуть через ту галіму віртуалізацію, погнало начальство інтенсивно "любити лінукс". В рамках нової усміхненої політики.
Тю. Так уже скоро як пів року, як макрософт платиновий член linux foundation. Ви навіть не в курсі?
Зайдіть сюди.
Ваш макрософт пузатий корпоративний платиновий члєн. :8:

Повідомлення відредагував kalamar: 13.04.2017 – 01:51

  • 0

#93 kalamar

    Старійшина

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 3989 повідомлень
  • Стать:Чоловік
  • Місто:Чорнильщина

Відправлено 13.04.2017 – 02:36

Перегляд допису_Ex (12.04.2017 – 20:21) писав:

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

Повідомлення відредагував kalamar: 13.04.2017 – 02:37

  • 0

#94 _Ex

    STATUS_OK

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 1629 повідомлень
  • Стать:Чоловік
  • Місто:Бахмут, Південна Слобожанщина, Україна

Відправлено 13.04.2017 – 14:35

Так, вони "люблять лінукс", я чув. <_< Шо я можу сказати. Тепер є за шо ненавидіти МС. :lol:
Мене ці ігри не цікавлять.
Це не аналог віне. Це підсистема середовища. Я тут про це писав писав. Як і про зношування флешу. Ніхто ж не читає. NT має таку концепцію з самого початку. Це впорядкований спосіб надати програмам звичне їм програмне середовище і API. віне важко назвати "впорядкованим", чи "повним" програмним середовищем. Нема там ані повноти, ані справжньої ефективної інтеграції. справді - кривокоса програма емулятор, яка з величезним оверхедом, вміє обслуговувати лише жалюгідну підмножину інтерфейсу.
Я тепер їм раджу зібратися, і перенести на віне, оцю лінукс підсистему. :wacko: Плюс - все це на віртуальній машині. :lol: Фани обпісяються від радости.

Цитата

Щодо флешок, то їх зазвичай в fat форматують, адже вони для перенесення інформації, а вінда ніц, крім своїх файлових систем, не вміє.
Вінда вміє будь яку ФС. Просто напишіть IFS драйвер. Добре визначений інтерфейс для цього. І не треба нічого переконпілірувати. Тим паче - переписувати під кожну нову версію ядра. ;) Наприклад існують такі драйвери для ext2/3. Мабуть відповідь трохи в іншій площині лежить - 1) Фат дуже підходе всім (на маленьких носіях, як флешки), бо вона проста і швидка. Недарма ж саме її взяли як свою такі стандарти як SD і UEFI. І 2) - лінуксові ФС нікого нічим не привабили. Шо і не дивно, та заздрісна піська, яка головна там, вмудрилась скурвити всіх своїми тупими заявами. Не кажучи, шо вони там щомісяця винаходять "нову революційну ФС для лінукса", з потворною назвою, і шо головне - яку через півроку самі закидають. По тій сцилці на мороніксі, перша ж "свіжа" стаття в списку, - якраз про таку фігню.

Перегляд дописуkalamar (13.04.2017 – 00:23) писав:

Ну не послухалися розробники ext чи райзера вашої авторитетної думки, і їх файлові системи дозволяють вибирати рівень журналювання. При монтуванні можна вказати, що ви хочете журналювати.
і ніхто тим не користується. бо воно повільне як чорт.
не знаю такої статистики, але не здивуюсь якшо виявиться, ~90% користувачів, які використовують журнальовані ФС, використовують саме цей, найоптимальніший підхід, - журналювання лише метаданих.
На ОПК, де нажаль один лінукс, вимикають журналювання на ext4 взагалі.

Цитата

В мене летіла fat32 під віндою після вимкнення електрики. Нічого незвичайного тут нема.
Чому ви вирішили, що дані обов’язково цінні мають бути? На кий біс робити бекапи різного роду сміття скачаного з нету? Але коли полетить, все одно неприємно.
FAT32 це не журнальована система. Якшо вимкнеться електика під час транзакції на ФС яка журналює лише метадані, максимум шо ви втратите, це той шматок файла який не встиг запизатися. Грубо кажучи 1 файл (точніше - його найновішу версію).

Повідомлення відредагував _Ex: 13.04.2017 – 14:36

  • 0

#95 _Ex

    STATUS_OK

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 1629 повідомлень
  • Стать:Чоловік
  • Місто:Бахмут, Південна Слобожанщина, Україна

Відправлено 13.04.2017 – 15:10

Розказуючи в одному з попередніх дописів за перші потоки і спроби втулити в них UI функціоналінсть, я там сказав, шо справжнє користувацьке введення ще довго буде лише фантастикою, через складність імлементації USB стеку. Це все так, про складність. Але, я забув за наш термінал! :facepalm: У нас же уже є з'єднання з дисплеєм і клавіатурою через термінальне з'єднання. Ми вже навіть уміємо писати туди. Забув за це. Звичайно перші спроби UI мають іти саме через це з'єднання. І воно стосується не лише введення, виведення звичайно теж.
Тобто в тій нашій картинці, спочатку, замість hdmi+lcd+x2d і тим паче USB HID миши й клави, ми маємо зв'язку UART + термінальний драйвер, хай буде term.sys, термопсис. :D
UART драйвер просто пише/читає в/з послідовний(ого) порт(а). термінальний драйвер використовує це, а зверху надає потрібну трансляцію і відображення на вхідні/вихідні консольні буфери. Фільтр драйвер?
А далі іде консольне API, яким користуватиметься наш консольний потік, і яке оперує на тих буферах.
Ще треба вигадати абстракції і зв'язування між "сирими" буферами уарта і стандартними потоками В/В. Там потрібен не лише траснлятор, але й "перемикач", тобто механізм зв'зування, - на яку саме апаратуру попаде наприклад "стандартне виведення" - на уарт, чи на hdmi-дисплей, чи на обидва. те саме з введенням.
  • 0

#96 kalamar

    Старійшина

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 3989 повідомлень
  • Стать:Чоловік
  • Місто:Чорнильщина

Відправлено 13.04.2017 – 19:35

Перегляд допису_Ex (13.04.2017 – 14:35) писав:

Так, вони "люблять лінукс", я чув. <_< Шо я можу сказати. Тепер є за шо ненавидіти МС. :lol:
Та не кажіть, треба думати про перехід на Haiku, туди наче ше не дістали їх криві руки.

Перегляд допису_Ex (13.04.2017 – 14:35) писав:

Мене ці ігри не цікавлять.
Це не аналог віне. Це підсистема середовища. Я тут про це писав писав. Як і про зношування флешу. Ніхто ж не читає. NT має таку концепцію з самого початку. Це впорядкований спосіб надати програмам звичне їм програмне середовище і API. віне важко назвати "впорядкованим", чи "повним" програмним середовищем. Нема там ані повноти, ані справжньої ефективної інтеграції. справді - кривокоса програма емулятор, яка з величезним оверхедом, вміє обслуговувати лише жалюгідну підмножину інтерфейсу.
Ви, як завжди, помиляєтесь. (я теж читав там у них про те, що NT має таку концепцію з самого початку <_< , і подібні ля-ля-ля, це реклама, на яку ви легко купуєтесь ). wine не емулятор, це реалізація API windows, тобто, практично те саме, що ваяють ваші кумири. От dosbox це емулятор.
Овергед в вайні не такий уже і великий. Якщо іграшка добре вайном підтримується, то на віндовз вона йде на якихось 20-30 відсотків швидше.
  • 0

#97 _Ex

    STATUS_OK

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 1629 повідомлень
  • Стать:Чоловік
  • Місто:Бахмут, Південна Слобожанщина, Україна

Відправлено 13.04.2017 – 20:45

Самі ви "реклама". Ви просто не шарите тут. не шарите. В NT була підсистема для WinAPI, OS/2 і POSIX. З самого початку. Шоб відчути різницю між "є концепція" і "нема концепції", вам треба це намагатися зробити, і треба знати за це більше. Якшо взяти по 10 найкрутіших спеціалістів з обох сторін і дати їм завдання відтворити ефективно програмне середовище противної сторони в своїй ОС, то от вони б почули різницю. Хто швидше зробе? Чиє швидше бігатиме? Це залежить від фундації яка вже є в системі. В Вінді є така, і МС уже написав лінуксову ПС, боси скомандували. В крепексі? Угу, є Вайн. :lol:
Якби віне був не емулятором, він би створював повнофункціональне WinAPI. Але на глинуксі таке ж і не можливо - там же нема ніякої структурного простору для цього. там нема взагалі ніякої структури. ви поняття не матимете, як туди адаптувати якийсь програмний інтерфейс ефективно. яка там розширюваність і адаптивність. як розширити системні сервіси для ефективної імплементації специфічних Віндовс речей? Як втілити відповідну конфігураційну БД. Сервіси? Графічна підсистема, GDI, DirectX, COM, .NET? Все можливо звичайно, треба просто взяти і переписати лінукс в Віндовс. Якихсь вбудованих можливостей розширятися і адаптувати нові програмні інтерфейси там нема. Бо то шлак. Шо ваш вайн робитиме наприклад, якшо WinAPI програма пише в реєстр? Він дасть їй справжній ефективний реєстр? Справжінй бінарний (== швидкий) реєстр, з кошолками і вуликами? :lol: Лололо. я не здивуюсь якшо ті жопоруки генерують якісь "текстові" файли, які на льоту переганяють в реєстрові запити програми. :facepalm: Емулятор, емулятор. Він не імплементує WinAPI нативно, а переганяє їх в лінуксові (юзерспейсні) відповідники. Це робе його емулятором API і це ж дає оверхед і загальну неюзабелність. Кишка в них тонка відтворити в крепексі таку гігантську систему як WinAPI. Це була б їхня заповітна мрія, якби вони могли.
На лінуксі нема ніякої модулярности, вся модулярність там, це те шо "драйвери" це просто об'єктні файли не впиляні в ядро. Це навіть не динамічні бібліотеки. Це сором. нема моделі драйверів, нема стабільного API для драйверів. Постачальники драйверів мають увесь час переробляти їх під нові костилі в ядрі. Подивіться які версії крепекса на комерційних продуктах на ньому базованих. Аж ніяк не найновіші. Навпаки це древність типу 3.0.8. Це я вам справжній приклад надав - це версія крепекса, яку підтримує Ingenic для SoC на платі, на якій я ось роблю тут, оце все, за шо пишу. І це тотально так. Не лише китайські вендори соків. по всьому фронті аж до червоного капелюшка. чого так? та хто ж кайфуватиме від переробляння всього, шо стіке пилялося. Тим паче в тому безструктурному звалищі. А от на Він10 драйвери з'явилися від усіх виробників одразу. Ще сама десятка не встигла вийти, вже драйвери на неї готові. Для усього. "Реклама"
На Вінді є справжня модулярність і розширюваність. Є стабільна модель драйверів. Ви можете додати імплементацію посикса в ефективний спосіб, нативно, без переганяння одних викликів в інші, як робе те убожество вайн. Мікрософт саме це й зробив для лінукса (нашось). Так само вони допиляли той гівняний Git вставивши фільтр-драйвер для того, шоб можна було юзати цей гіт краще, для такої гігантської кодової бази яку вони мають. це вже інше питання, нашо їм це. Я тут ілюструю гнучкість і потужність системи - всирається Гіт на такій велетеньскій кодовій базі, а вони його вибрали, задовліьняючи новомодні забаганки керівництва, уніфікуючи свій інструментарій. Шо робити? Вони беруть і з мінімумом зусиль роблять йому "файлову систему" - фільтр драйвер який виправляє хрому масштабованість гіта. "мінімальні зусилля" тут ключове слово, бо знову ж - лінукс теж можна зробити нормальним, отак - "лінукс" -> Ctrl+A -> Del -> "написати нормально цього разу".
і воно оте все - підсистеми, віртуальна ФС для гіта, і тд, воно справді модульне і завдяки розширюваності системи. Треба - воно запустилося, не треба, воно навіть не завантажене. Не треба нічого "переконпілірувати", не треба нічого "мейнлайнити". А у вас, в лінуксі вашому, в ядро впиляне все лайно яке туди вони наклепали. Чи воно вам треба чи не треба, воно валяється у вас в пам'яті. Але це пів біди, воно ж перезавантажує систему, адже треба перебирати чи оце треба чи може оце, або ні, може оте. Наприклад почитайте як лінукс вибирає яку ж конфігурацію юзати DT чи ACPI. "пробують", "пробують" поки весь хлам не перепробують. Та напишіть ви вже нормально те ACPI, всеодно доведеться його прийняти, вас ніхто не питатиме подобається воно вам чи ні, і винайти шось гоже ви не в змозі, ті ж Дерева Пристроїв - бездарно видрані з OpenFirmware. І ліпляться вони на тому армі, як козі ковзани. Ядро на старті займається читанням перебиранням тесктових рядочків "описання заліза" і сованням кожної чисельної "клітини" big-endian DT в little-endian. А якже - дуже прогресивно, дуже. Кодові шляхи виходять довжелезні. Я вже показував вам значно більше завантаження процесора в лінуксі. це все звідтіля - гора хламу, яка робе тіке того, шо її пиляли поки вона не заробила. Скільки там уже нових революційних графічних систем на лінуксі? Gallium, Wayland. Вже всю таблицю Менделеєва перебрали? Всю географію американську? І хоч одна робе нормально, хоч би близько як на Вінді?
лінукс потрібен. шоб дивитися на нього і не робити як в ньому зроблено.

Повідомлення відредагував _Ex: 13.04.2017 – 20:52

  • 0

#98 kalamar

    Старійшина

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 3989 повідомлень
  • Стать:Чоловік
  • Місто:Чорнильщина

Відправлено 13.04.2017 – 22:41

Перегляд допису_Ex (13.04.2017 – 20:45) писав:

Самі ви "реклама". Ви просто не шарите тут. не шарите.
Не пишіть простирадел. В вінді всього навсього зробили командний інтерфейс башу. sigwin вам і раніше давав в вінді баш. Порівньювати з вайном то смішно. Якщо вони захочуть повозитись з зоопарком графічних тулкітів лінукса, тоді побачимо. Хоча, тулкіти теж давно портовані без участі мікрософт. Я на вінді треті кеди запускав.

Ось цікаве питання.

Повідомлення відредагував kalamar: 13.04.2017 – 22:59

  • 0

#99 _Ex

    STATUS_OK

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 1629 повідомлень
  • Стать:Чоловік
  • Місто:Бахмут, Південна Слобожанщина, Україна

Відправлено 13.04.2017 – 23:25

ото ж. смішно витрачати час на портування кривих поробок, маючи найпотужнішу в світі програмну екосистему, яка має все.

командний POSIX-сумісний інтерпретатор і я вам напишу (от побачите :lol:), там все ж "трохи" більше. хоча я цілком згоден - це марнота марнот. єдине, шо мені постійно хочеться на це сказати: "краще б ви підтримку Ітаніуму відновили", якшо вже час нікуди дівати.
хоча ніде правди діти - існує купа людей звиклих до дрокання в баші, і які б залюбки втілили своє потаємне бажання робити це на Віндовс. зустрічав опиншмопин ентузіастів, які рвонули це робити ледь не в перший день як та шняга вийшла на світ. расовоповноцінніше було б уже зробити труЬ POSIX-сумісну підсистему. Ще й сертифікацію отримати, шоб крепексоїди луснули. :lol: Піара б не вийшло. фан-хлопчики ж не у POSIX'а.

я тепер писатиму інші простирадла, годі базікати! ось короткі намітки на найближче майбутнє (хоч я й не люблю планувати його). мене чекають:
  • DDRC і DDRP парочка - код майже написано, та все ж.
  • ELF2PE транслятор - вивчено тіке "основи", програму ще писати. оскільки я не вмію пітон, утиліту писатиму на C. Це краще, але мабуть довше. Нащастя, через отаку опцію гнусного лінкувальника як -q, життя покращується, адже так можна знайти релокації навіть в вихідному ельфі. правда для наших "ядерних" компонентів, релокації не потрібні (бо ми не ребазуємо їх). це потрібно загалом.
  • ACPI таблиці (все дуже запущено)
  • зародок Hal, а в ньому: контроллер переривань, обробник таймера і обробники винятків (де мають бути обробники винятків Tlb?)
  • зародок Ke, а в ньому: диспетчер винятків і переривань, початки потокового диспетчера, об'єктного менеджера, В/В менеджера (разом з PnP менеджером і павер менеджером), менеджера пам'яти - тут всього 32 Tlb записи, це дуже мало, того треба укрупнювати фізичні сторінки, це ускладнить і до того один з найскладніших компонентів.
  • драйвер Uart.
  • драйвер SD
  • драйвер Fat
Оптимістично, - це до нового року навигадував собі занять.) Шоб ви розуміли - під "драйверами" теж маються на увазі їхні зародки. Я може й наївний, але не настільки, шоб вважати, шо одразу вийдуть повнофункціональні весчі. :)
  • 0

#100 kalamar

    Старійшина

  • Користувачі
  • PipPipPipPipPipPipPipPipPipPip
  • 3989 повідомлень
  • Стать:Чоловік
  • Місто:Чорнильщина

Відправлено 13.04.2017 – 23:50

Перегляд допису_Ex (13.04.2017 – 23:25) писав:

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

Повідомлення відредагував kalamar: 13.04.2017 – 23:58

  • 0



Кількість користувачів, що читають цю тему: 3

0 користувачів, 3 гостей, 0 анонімних


Магазин кубиков Рубика Cubes.in.ua