Смарт или виртуални хардуерни драйвери
Като начало, нека въведем дефиницията на bus master: устройство, способно да бъде не само slave, но и master на компютърната шина. Тоест, не само да отговарят на I / O транзакции, инициирани от процесора, но и да ги инициират независимо - по собствена инициатива, „влизат“ в паметта.
Вече в режим DMA работата на драйвера изглежда значително по-различна - от драйвера не се изисква да извършва I / O, а да подготви настройки за устройството, да го активира, да изчака прекъсване в края на I / O и да провери успеха на операцията. Всичко казано в предишната статия е вярно и за DMA устройствата, но в допълнение към казаното, драйверът трябва да разбере схемата на взаимодействие между устройството и DMA контролера и понякога изрично да разпредели и конфигурира контролера: ако в старите устройства обвързването на I / O порта към DMA контролера беше направено фиксирано, сега в много случаи е възможно пълно маршрутизиране или избор на DMA канал от 2-4 опции.
Отделно трябва да се отбележи, че самото иницииране на следващата I / O транзакция може да бъде автоматично (DMA бие с възможно най-висока скорост), автоматично с настройка на темпото (за да не се изяде цялата честотна лента на шината) или по събитие.
В този случай събитие в развитите системи може да бъде прекъсване, просто промяна в състоянието на извода на микроконтролера или друго устройство може да бъде източник на събитието. Например таймер. Това ви позволява да свържете заедно DAC, DMA машината и таймера, така че следващият байт да се подава в DAC на определена честота (таймер). Има и други опции за агрегиране на устройства, като активиране на един DMA канал, когато друг е завършен. Без да привлича вниманието на процесора.
Също така е подходящо да се каже, че DMA контролерите понякога са в състояние изрично да съпоставят двойка канали,за да се осигури непрекъснатост на потока от данни, в края на работата на един канал се стартира вторият и се генерира прекъсване, според което процесорът отново зарежда първия канал - за същия DAC това може да бъде жизненоважно.
Да се върнем от света на контролерите към "възрастните" машини. Повечето съвременни входно-изходни подсистеми вече не се базират на външен DMA, а имат негов аналог точно вътре.
Това са устройства с режим "bus master", bus master.
Най-лесно е да си ги представим като устройства, които имат вграден персонален и оптимално подреден DMA контролер.
В допълнение към структурата на дескриптора, такова устройство също изисква инструменти за обмен на събития: процесорът трябва да може да докладва, че е променил или добавил дескриптори, а устройството трябва да може да докладва, че частично или напълно е завършило I / O. Вторият се изпълнява, разбира се, чрез прекъсвания, а за първия често се използва регистър (звънец), на който процесорът „чука“, за да привлече вниманието на устройството към промените.
Съществува обаче опасност да се промени точно това, което устройството обработва в момента, което налага допълнителни ограничения върху структурата на драйвера.
Отделно в този ред са виртио уредите. Те се появиха в резултат на победния марш на хипервизорите по света. Традиционно хипервайзорът предлагаше на ОС за гости набор от виртуални устройства, които копираха едно или друго популярно физическо устройство. Известна мрежова карта или дисков контролер. Но е трудно, неудобно и досадно да се емулира „желязно“ устройство - често трябва да поддържате свойства, които са напълно ненужни във виртуалния свят, докато за целите на виртуализацията структурата на истинско желязно устройство обикновено не е оптимална.
In virtio драйвери на ядротопопълва пакета и иска от генеричния драйвер на vitio да го "предаде" на устройството. Сега, докато устройството не „предаде“ пакета обратно, не можете да го докоснете. Обратно, ако устройството може да въвежда данни по външна инициатива, то трябва да изпрати няколко празни (подготвени за четене) пакета - когато данните пристигнат (например входящи мрежови съобщения), пакетите ще бъдат попълнени и прехвърлени обратно към ядрото на гост OS.
В допълнение, стандартът virtio поддържа възможността ядрото и устройството да договарят режимите на работа и поддържаните функции по стандартен начин. Например мрежовият драйвер на virtio може или не може да чете и вмъква контролна сума в IP пакетите, които изпраща.
В някои операционни системи (Phantom "копира" това от NT, откъде са го копирали - не знам) има стандартна поддръжка за изпълнение на код в "леки" нишки - Deferred Procedure Call. Това ви позволява да намалите времето, прекарано от драйвера в прекъсването: манипулаторът на прекъсване улавя само събитието и като максимум чете състоянието от устройството - един регистър. Останалото се прави в DPC, който бързо се активира и довършва започнатото.
Честно казано, няма толкова много смисъл в това - по-лесно е да стартирате собствена нишка с висок приоритет в драйвера и да правите I/O от нея. Възможно е обаче да има варианти. Можете да разпределите DPC приоритетна група и да гарантирате, че те винаги имат по-висок приоритет от нишката. Възможно е да се осигури ултра-бързо планиране и прехвърляне на процесора към такива нишки точно на изхода от точно прекъсването, което този DPC поиска, намалявайки латентността.
Отделно отбелязваме, че много от това, което е невъзможно при прекъсване, е възможно от DPC. Какво точно зависи от ОС. Всичко е възможно във Phantom в DPC, включително заспиване за един месец. Грях, но възможно. NT, EMNIP, все пак някакограничава правата на DPC (тоест това не са обикновени теми), но не помня подробности.
С това смятам, че съм изпълнил дълга си към водачите. :)