A hardver-illesztőprogramok, eszközmeghajtók vagy driverek olyan számítógépes programok, melyek lehetővé teszik más programok számára a számítógép hardvereszközeivel való kommunikációt.[1]

A Gallium3D és a Direct Rendering Infrastructure (Mesa 3D) hardver-illesztőprogram modellek

Más szavakkal az illesztőprogram vagy egy interfész (köztes elem) az eszközzel való kommunikációban, vagy emulálja az eszközt. Az illesztőprogramok általában egy adatbuszon vagy azon a kommunikációs alrendszeren keresztül érik el a hardvereszközt, ahová az csatlakozik.

Mikor egy program előhív egy szubrutint az illesztőprogramból, az illesztőprogram utasításokat küld a hardvereszköz felé, majd amikor az eszköz küld vissza adatot, az illesztőprogram hív elő (szub)rutinokat a programban.

Az illesztőprogramok hardverfüggőek és rendszerspecifikusak. Általában kezelik azokat a megszakításokat, amelyek az aszinkron időfüggő hardvercsatoláshoz szükségesek lehetnek.[2]

Célja szerkesztés

Az eszközillesztő fő célja az absztrakció biztosítása azáltal, hogy átalakítóként működik a hardver eszköz és az azt használó alkalmazás vagy operációs rendszer között.[3] A programozók magasabb szintű alkalmazáskódot írhatnak a végfelhasználók által használt bármilyen hardvertől függetlenül. Például egy soros porttal kölcsönhatásban lévő fejlett alkalmazásnak csak két funkciója lehet: "adatok küldése" és "adatok fogadása". Alsó szinten az ezeket a funkciókat megvalósító eszközillesztők kommunikálni fognak egy, a felhasználó számítógépére telepített saját soros port vezérlővel. A 16550 UART vezérléséhez szükséges parancsok meglehetősen különböznek az FTDI soros port átalakító vezérléséhez szükséges parancsoktól, de mindegyik hardverspecifikus eszközillesztõ ugyanarra (vagy hasonló) szoftver interfészre vonja össze ezeket a részleteket.

Fejlődés szerkesztés

Az eszközillesztők írásához mélyreható megértésre van szükség arról, hogy a hardver és a szoftver hogyan működik egy adott platformfunkciónál. Mivel az illesztőprogram futtatásához alacsony szintű hozzáférésre van szükség a hardveres funkciókhoz, az illesztőprogram általában rendkívül privilegizált környezetben fut. Ha probléma lép fel, az a rendszer működési problémáit okozhatja. Ezzel szemben a modern operációs rendszereken a legtöbb felhasználói szintű szoftver leállítható, anélkül, hogy a rendszer többi részére jelentős hatást gyakorolna. Ha az eszközt helytelenül programozták, még a felhasználói módban futtatott illesztőprogram is összeomolhat. Ezek a tényezők megnehezítik és veszélyessé teszik a problémák diagnosztizálását. [4]

Ezért az illesztőprogramok írásának feladata általában a szoftverfejlesztőkre vagy a hardverfejlesztő vállalatoknál dolgozó számítógépes mérnökökre tartozik. Ennek oka, hogy jobb hardvertervezési információval rendelkeznek, mint a legtöbb kívülálló. Ezenkívül hagyományosan úgy gondolják, hogy a hardvergyártók érdeke annak biztosítása, hogy ügyfeleik a lehető legjobban tudják használni hardverüket. Általában a logikai eszközillesztőket (LDD) az operációs rendszerek gyártói írják, a fizikai eszközillesztőket (PDD) pedig az eszközgyártók. Az elmúlt években azonban a nem gyártók nagyszámú eszközillesztőt írtak saját tulajdonú eszközökhöz, főleg ingyenes és nyílt forráskódú operációs rendszerek számára. Ebben az esetben nagyon fontos, hogy a hardvergyártó információkat szolgáltasson arról, hogyan kommunikál az eszköz. Bár ezeket az információkat ki lehet nyerni mérnöki visszafejtés útján, a hardver sokkal nehezebb, mint a szoftver.

A Microsoft egy új illesztőprogram-fejlesztési keretrendszer létrehozásával próbálta csökkenteni a helytelenül írt eszközillesztők okozta rendszer instabilitását. Ide tartozik a User Mode Driver Framework (UMDF) is, amely felhasználói módú illesztőprogramokként ösztönzi bizonyos típusú illesztőprogramok fejlesztését - főleg olyanok fejlesztését, amelyek üzenetrögzítő protokollokat valósítanak meg eszközükkel való kommunikáció céljából. Ha az ilyen illesztőprogramok meghibásodnak, nem okoznak instabilitást a rendszerben. A kernel-mode driver keretrendszer (KMDF) továbbra is lehetővé teszi a kernel-mode eszközillesztők fejlesztését, de megkísérli az ismert problémákat okozó funkciók szabványos megvalósítását, ideértve az I/O műveletek törlését, az energiagazdálkodást és a plug-and-play támogatását az eszközökön.

Az Apple nyílt forráskódú keretrendszerrel rendelkezik az illesztőprogramok fejlesztésére a macOS-on, I/O Kit néven.

Linux környezetben a programozók eszközmag-illesztőprogramokat készíthetnek a kernel részeként, önmagában betölthető modulként, vagy felhasználói módú illesztőprogramként (bizonyos rendszermag-interfészekkel rendelkező eszközök, például USB-eszközök számára). A Makedev felsorolja az eszközök listáját a Linuxban, beleértve a ttyS (terminál), az lp (párhuzamos port), a hd (lemez), a hurok és a hang (ezek közé tartozik a keverő, a szekvenszer, a dsp és az audio). [5]

A Microsoft Windows .sys fájlok és a Linux .ko fájlok tartalmazhatnak betölthető eszközillesztőket. A betölthető eszközillesztők előnye, hogy csak szükség esetén tölthetők be és tölthetők le, így spórolva a rendszermag memóriáját.

Kernel mód és felhasználói mód szerkesztés

Az eszközillesztők, különösen a modern Microsoft Windows platformokon, kernel módban (0 csengés x86-os processzorokon[forrás?]) vagy felhasználói módban (3. csengés x86-os CPU-n[forrás?]) futtathatók.[6] Az illesztőprogram felhasználói módban történő futtatásának fő előnye a stabilitás javítása, mert a helytelenül megírt felhasználói módú eszközillesztők nem fogják összeomlani a rendszert a rendszermag memóriájának felülírásával. Másrészről, a felhasználó / kernel mód átalakítása általában jelentős teljesítményt eredményez, így a kernel módú illesztőprogramok az első választás az alacsony késésű hálózatoknál.

A rendszermag területet a felhasználói modul csak rendszerhívások segítségével érheti el. A végfelhasználói programok, mint például a UNIX shell vagy más GUI-alapú alkalmazások, a felhasználói tér részét képezik. Ezek az alkalmazások a rendszermag által támogatott funkciók révén lépnek kapcsolatba a hardverrel.

Alkalmazások szerkesztés

A felhasználói modulok csak rendszermeghívások segítségével férhetnek hozzá a kern-térhez. A végfelhasználói programok (például UNIX-héjak vagy más GUI-alapú alkalmazások) a felhasználói tér részét képezik.[7] Ezek az alkalmazások a kernel által támogatott funkciókon keresztül lépnek kapcsolatba a hardverrel.

Az eszközillesztők absztrakciójának általános szintjei a következők:

  • Hardver esetén:
    • Közvetlen interfész
    • Írás vagy olvasás eszközvezérlő regiszterbe
    • Néhány magasabb szintű interfész (pl Video BIOS )
    • Másik alacsonyabb szintű eszközillesztő használata (pl. Fájlrendszer-illesztőprogramok lemezmeghajtókat használva)
    • A hardveres munka szimulálása, miközben egészen mást csinál [8]
  • Szoftverhez:
    • Az operációs rendszer közvetlen hozzáférésének lehetővé tétele a hardver erőforrásokhoz
    • Csak primitívek megvalósítása
    • Interfész megvalósítása nem illesztőprogram-szoftverekhez (pl TWAIN )
    • Néha meglehetősen magas szintű nyelv (pl PostScript )

Ezért az adott hardverhez megfelelő eszközillesztő kiválasztása és telepítése általában a számítógépes rendszerkonfiguráció kulcsfontosságú eleme. [9]

A virtuális eszközillesztő az eszközillesztő meghatározott változatát képviseli. Hardvereszközök szimulálására szolgálnak, különösen virtualizált környezetekben, például amikor DOS program fut Microsoft Windows számítógépen, vagy amikor vendég operációs rendszer fut Xen gazdagépen. A virtuális eszközillesztő nem engedi, hogy a vendég operációs rendszer beszéljen a hardverrel, hanem ellentétes szerepet játszik és szimulálja a hardvert, hogy a vendég operációs rendszer és a virtuális gépben futó illesztőprogramok illúziót teremtsenek a valódi hardver eléréséről. . A vendég operációs rendszer hardver elérésére tett kísérleteit a fogadó operációs rendszer virtuális eszköz-illesztőprogramjaira irányítják, például a funkcióhívásokra. A virtuális eszközillesztő szimulált processzor szintű eseményeket (például megszakításokat) is küldhet a virtuális gépre.

A virtuális eszközök nem virtualizált környezetben is futhatnak. Például virtuális hálózati adaptereket használnak virtuális magánhálózatokhoz, és virtuális lemezes eszközöket használnak az iSCSI-hez. A virtuális eszközillesztőre jó példa a Daemon Tools.

A virtuális eszközillesztőknek számos változata létezik, például VxD, VLM és VDD.

Nyílt forráskódú illesztőprogramok szerkesztés

  • Grafikus eszközillesztő
  • Nyomtatók: CUPS
  • RAID-fájlok: CCISS [10] (Compaq parancssori felület az SCSI-3 támogatáshoz [11] )
  • Szkennerek: SANE
  • Videó: Vidix, Direct Rendering Infrastructure

A gyakran használt eszközillesztők Solaris-leírásai:

  • fas: Gyors / széles SCSI vezérlő
  • hme: Gyors (10/100 Mbit / s) Ethernet
  • isp: Differenciál SCSI vezérlők és a SunSwift kártya
  • glm: (Gigabaud Link modul [12] ) UltraSCSI vezérlők
  • scsi: SCSI (Small Computer Serial Interface) eszközök
  • sf: soc + vagy socal Fibre Channel választott hurok (FCAL)
  • soc: SPARC Storage Array (SSA) vezérlők és a vezérlő eszköz
  • socal: Soros optikai vezérlők az FCAL számára (soc +)

API-k szerkesztés

  • Windows Display Driver Model (WDDM) - a grafikus megjelenítő illesztőprogram architektúrája Windows Vista, Windows 7, Windows 8 és Windows 10 rendszerekhez .
  • Egységes hangmodell (UAM) [13]
  • Windows Driver Foundation (WDF)
  • Deklaratív összetett hardver (DCH) - univerzális Windows Platform illesztőprogram [14]
  • Windows illesztőprogram-modell (WDM)
  • Network Driver Interface Specification (NDIS) - szabványos hálózati kártya illesztőprogram API
  • Advanced Linux Sound Architecture (ALSA) - as of 2009 a szokásos Linux hang-illesztő felület
  • Scanner Access Now Easy (SANE) - egy nyilvános felület a raszteres képolvasó-hardverhez
  • Telepíthető fájlrendszer (IFS) - fájlrendszer API az IBM OS / 2 és a Microsoft Windows NT számára
  • Open Data-Link Interface (ODI) - az NDIS-hez hasonló hálózati kártya API
  • Uniform Driver Interface (UDI) - egy platformon átívelő illesztőprogram-interfész projekt
  • Driver Framework (dxd) - C ++ nyílt forráskódú, cross-platform meghajtó keretrendszer a KMDF és az IOKit számára[15]

Azonosítók szerkesztés

A PCI buszon vagy USB-n lévő eszközöket két azonosító azonosítja, és mindegyik azonosító 4 hexadecimális számjegyből áll. A szállítóazonosító azonosítja az eszköz szállítóját. Az eszközazonosító egy adott eszközt azonosít az adott gyártótól/szállítótól.

A PCI-eszköz általában rendelkezik egy azonosító párral az eszköz fő chipjéhez és egy alrendszer azonosító párral, amely azonosítja a szállítót, amely eltérhet a chip gyártójától.

Jegyzetek szerkesztés

  1. What is all device driver?. WhatIs.com . TechTarget. (Hozzáférés: 2018. március 19.)
  2. EMC Education Services. Information Storage and Management: Storing, Managing, and Protecting Digital Information. John Wiley & Sons (2010). ISBN 9780470618332 
  3. What is all device driver?. WhatIs.com . TechTarget. (Hozzáférés: 2018. március 19.)
  4. Burke, Timothy. Writing device drivers: tutorial and reference. Digital Press (1995). ISBN 9781555581411 
  5. MAKEDEV — Linux Command — Unix Command. Linux.about.com, 2009. szeptember 11. [2009. április 30-i dátummal az eredetiből archiválva]. (Hozzáférés: 2009. szeptember 17.)
  6. User-mode vs. Kernel-mode Drivers. Microsoft, 2003. március 1. [2008. március 9-i dátummal az eredetiből archiválva]. (Hozzáférés: 2008. március 4.)
  7. Deborah Morley. Understanding Computers 2009: Today and Tomorrow. Cengage Learning (2009). ISBN 9780324830132 
  8. Computer Peripherals and Interfaces. Technical Publications Pune, 5–8. o. (2008. január 1.). ISBN 978-8184314748. Hozzáférés ideje: 2016. május 3. [halott link]
  9. What are Device Drivers and why do we need them?. drivers.com, 2015. április 17. (Hozzáférés: 2018. március 19.)
  10. CCISS. SourceForge, 2010. (Hozzáférés: 2010. augusztus 11.) „Drivers for the HP (previously Compaq) Smart Array controllers which provide hardware RAID capability.”
  11. Russell, Steve. Abbreviations and acronyms. IBM International Technical Support Organization, 207. o. (2003. október 21.). ISBN 0-7384-2684-9. Hozzáférés ideje: 2011. augusztus 14. [halott link]
  12. US Patent 5969841 - Gigabaud link module with received power detect signal. PatentStorm LLC. [2011. június 12-i dátummal az eredetiből archiválva]. (Hozzáférés: 2009. szeptember 8.) „An improved Gigabaud Link Module (GLM) is provided for performing bi-directional data transfers between a host device and a serial transfer medium.”
  13. Unified Audio Model (Windows CE 5.0). msdn.microsoft.com. (Hozzáférés: 2016. szeptember 19.)
  14. Dell US: What are DCH drivers and why do you need to know about them? | Dell US (amerikai angol nyelven). www.dell.com. (Hozzáférés: 2020. október 29.)
  15. driver framework: Main Page. driver. (Hozzáférés: 2016. szeptember 19.)

Kapcsolódó szócikkek szerkesztés

További információk szerkesztés