Enhetsdriver - Device driver

Denne artikkelen handler om enhetsdrivere for maskinvare. For andre programvaredrivere, se Driver (programvare) .

I databehandling er en enhetsdriver et dataprogram som driver eller styrer en bestemt type enhet som er koblet til en datamaskin eller automat . En driver en programvaregrensesnitt til maskinvareenheter, slik at operativsystemer og andre dataprogrammer trenger tilgang til maskinvare funksjoner uten å vite nøyaktige detaljer om maskinvaren som brukes.

En driver kommuniserer med enheten gjennom datamaskinbussen eller kommunikasjonsundersystemet som maskinvaren kobles til. Når et anropsprogram påkaller en rutine i driveren, sender sjåføren kommandoer til enheten. Når enheten sender data tilbake til driveren, kan sjåføren påkalle rutiner i det opprinnelige ringeprogrammet.

Drivere er maskinvareavhengige og operativsystemspesifikke. De gir vanligvis avbruddshåndteringen som kreves for ethvert nødvendig asynkront tidsavhengig maskinvaregrensesnitt.

Hensikt

Hovedformålet med enhetsdrivere er å gi abstraksjon ved å fungere som en oversetter mellom en maskinvareenhet og applikasjonene eller operativsystemene som bruker den. Programmerere kan skrive applikasjonskode på høyere nivå uavhengig av hvilken maskinvare sluttbrukeren bruker. For eksempel kan en applikasjon på høyt nivå for samhandling med en seriell port ganske enkelt ha to funksjoner for "sende data" og "motta data". På et lavere nivå vil en enhetsdriver som implementerer disse funksjonene kommunisere til den bestemte serielle portkontrolleren som er installert på en brukers datamaskin. Kommandoene som trengs for å kontrollere en 16550 UART er veldig forskjellige fra kommandoene som trengs for å kontrollere en FTDI seriell portomformer, men hver maskinvarespesifikke enhetsdriver trekker disse detaljene inn i det samme (eller lignende) programvaregrensesnittet.

Utvikling

Å skrive en enhetsdriver krever en grundig forståelse av hvordan maskinvaren og programvaren fungerer for en gitt plattformfunksjon . Fordi drivere krever lavt nivå tilgang til maskinvarefunksjoner for å fungere, opererer drivere vanligvis i et høyt privilegert miljø og kan forårsake systemdriftsproblemer hvis noe går galt. Derimot kan de fleste programvaren på brukernivå på moderne operativsystemer stoppes uten at det påvirker resten av systemet i stor grad. Selv drivere som kjører i brukermodus kan krasje et system hvis enheten er feilprogrammert . Disse faktorene gjør det vanskeligere og farligere å diagnostisere problemer.

Oppgaven med å skrive drivere faller derfor vanligvis på programvareingeniører eller datamaskiningeniører som jobber for maskinvareutviklingsselskaper. Dette er fordi de har bedre informasjon enn de fleste utenforstående om utformingen av maskinvaren. Videre ble det tradisjonelt ansett i maskinvareprodusenten interesse å garanti for at deres kunder kan bruke sin maskinvare i en optimal måte. Vanligvis skrives den logiske enhetsdriveren (LDD) av leverandøren av operativsystemet, mens den fysiske enhetsdriveren (PDD) implementeres av enhetsleverandøren. Imidlertid har ikke-leverandører de siste årene skrevet mange enhetsdrivere for proprietære enheter, hovedsakelig for bruk med gratis og åpen kildekode- operativsystemer . I slike tilfeller er det viktig at maskinvareprodusenten gir informasjon om hvordan enheten kommuniserer. Selv om denne informasjonen i stedet kan læres ved reverse engineering , er dette mye vanskeligere med maskinvare enn det er med programvare.

Microsoft har forsøkt å redusere systemstabilitet på grunn av dårlig skrevne enhetsdrivere ved å lage et nytt rammeverk for driverutvikling, kalt Windows Driver Framework (WDF). Dette inkluderer User-Mode Driver Framework (UMDF) som oppmuntrer til utvikling av visse typer drivere-først og fremst de som implementerer en meldingsbasert protokoll for kommunikasjon med enhetene sine-som brukermodusdrivere. Hvis slike drivere fungerer feil, forårsaker de ikke system ustabilitet. Den kjernemodus-driver Framework (KMDF) modellen fortsetter å tillate utvikling av enhetsdrivere kjernemodus, men forsøk på å tilveiebringe standardimplementeringer av funksjoner som er kjent for å forårsake problemer, inkludert kansellering av I / O-operasjoner, strømstyring og plugg og støtte for spilleapparater.

Apple har et åpen kildekode-rammeverk for utvikling av drivere på macOS , kalt I/O Kit.

I Linux- miljøer kan programmerere bygge enhetsdrivere som deler av kjernen , separat som lastbare moduler eller som brukermodusdrivere (for visse typer enheter der det finnes kjernegrensesnitt, for eksempel for USB-enheter). Makedev inkluderer en liste over enhetene i Linux, inkludert ttyS (terminal), lp ( parallellport ), hd (disk), loop og lyd (disse inkluderer mikser , sequencer , dsp og lyd).

Microsoft Windows .sys -filer og Linux .ko -filer kan inneholde lastbare enhetsdrivere. Fordelen med lastbare enhetsdrivere er at de bare kan lastes inn når det er nødvendig og deretter lastes ut, og dermed sparer kjerneminne.

Kjernemodus kontra brukermodus

Enhetsdrivere, spesielt på moderne Microsoft Windows- plattformer, kan kjøres i kjernemodus ( Ring 0 på x86 CPUer ) eller i brukermodus (Ring 3 på x86 CPUer). Den primære fordelen med å kjøre en driver i brukermodus er forbedret stabilitet, siden en dårlig skrevet enhetsdriver i brukermodus ikke kan krasje systemet ved å overskrive kjerneminnet. På den annen side pålegger bruker/kjernemodusoverganger vanligvis en betydelig ytelse overhead, og gjør kjernemodusdrivere foretrukne for nettverk med lav latens.

Kjerneplass kan bare nås av brukermodulen ved bruk av systemanrop. Sluttbrukerprogrammer som UNIX-skallet eller andre GUI-baserte applikasjoner er en del av brukerområdet. Disse programmene samhandler med maskinvare gjennom kjernestøttede funksjoner.

applikasjoner

På grunn av mangfoldet av moderne maskinvare og operativsystemer, opererer drivere i mange forskjellige miljøer. Drivere kan grensesnitt med:

Vanlige abstraksjonsnivåer for enhetsdrivere inkluderer:

  • For maskinvare:
    • Grensesnitt direkte
    • Skrive til eller lese fra et enhetsstyringsregister
    • Bruke et grensesnitt på et høyere nivå (f.eks. Video BIOS )
    • Bruke en annen enhetsdriver på lavere nivå (f.eks. Filsystemdrivere som bruker diskdrivere)
    • Simulere arbeid med maskinvare, mens du gjør noe helt annet
  • For programvare:
    • Gir operativsystemet direkte tilgang til maskinvareressurser
    • Implementere bare primitiver
    • Implementere et grensesnitt for programvare som ikke er driver (f.eks. TWAIN )
    • Implementere et språk, noen ganger ganske høyt nivå (f.eks. PostScript )

Så å velge og installere riktige enhetsdrivere for gitt maskinvare er ofte en sentral komponent i datasystemkonfigurasjonen.

Drivere til virtuelle enheter

Virtuelle enhetsdrivere representerer en bestemt variant av enhetsdrivere. De brukes til å etterligne en maskinvareenhet, spesielt i virtualiseringsmiljøer, for eksempel når et DOS program kjøres på en Microsoft Windows datamaskin eller når en gjest operativsystemet kjøres på, for eksempel en Xen vert. I stedet for å la gjestesystemet få dialog med maskinvare, tar virtuelle enhetsdrivere den motsatte rollen og emulerer et stykke maskinvare, slik at gjestens operativsystem og dets drivere som kjører inne i en virtuell maskin kan ha en illusjon av å få tilgang til ekte maskinvare. Gjestoperativsystemets forsøk på å få tilgang til maskinvaren dirigeres til den virtuelle enhetsdriveren i vertsoperativsystemet som f.eks.  Funksjonsanrop . Den virtuelle enhetsdriveren kan også sende simulerte hendelser på prosessornivå som avbrudd til den virtuelle maskinen.

Virtuelle enheter kan også fungere i et ikke-virtualisert miljø. For eksempel brukes et virtuelt nettverkskort med et virtuelt privat nettverk , mens en virtuell diskenhet brukes med iSCSI . Et godt eksempel for virtuelle enhetsdrivere kan være Daemon Tools .

Det er flere varianter av virtuelle enhetsdrivere, for eksempel VxD , VLM og VDD.

Drivere med åpen kildekode

Solaris -beskrivelser av vanlige enhetsdrivere:

  • fas: Rask/bred SCSI -kontroller
  • hme: Rask (10/100 Mbit/s) Ethernet
  • isp: Differensial SCSI -kontrollere og SunSwift -kortet
  • glm: (Gigabaud Link Module) UltraSCSI -kontrollere
  • scsi: Small Computer Serial Interface (SCSI) -enheter
  • sf: soc+ eller socal Fiber Channel Arbitrated Loop (FCAL)
  • soc: SPARC Storage Array (SSA) -kontrollere og kontrollenheten
  • socal: Serielle optiske kontrollere for FCAL (soc+)

APIer

Identifikatorer

En enhet på PCI -bussen eller USB -en identifiseres med to ID -er som består av 4 heksadesimale tall hver. Leverandør -ID -en identifiserer leverandøren av enheten. Enhets -ID -en identifiserer en bestemt enhet fra den produsenten/leverandøren.

En PCI -enhet har ofte et ID -par for enhetens hovedbrikke, og også et delsystem -ID -par som identifiserer leverandøren, som kan være forskjellig fra brikkeprodusenten.

Se også

Referanser

Eksterne linker