7.3. Oversikt over enhets og modul håndtering

I kapittel 6 installerte vi Udev pakken da eudev ble bygget. Før vi går inn i detaljene om hvordan dette fungerer, er en kort historie med tidligere metoder for håndtering av enheter i orden.

Generelt brukte Linux systemer tradisjonelt en metode for opprettelse av statiske enheter, hvorved mange enhetsnoder ble opprettet under /dev (noen ganger bokstavelig talt tusenvis av noder), uavhengig av om de tilsvarende maskinvareenhetene faktisk eksisterte. Dette ble vanligvis gjort via et MAKEDEV skript, som inneholder et antall kall til mknod programmet med relevante større og mindre enhetsnumre for alle mulige enheter som kan eksistere i verden.

Ved hjelp av Udev metoden er det bare de enhetene som oppdages av kjernen som får enhetsnoder opprettet for dem. Fordi disse enhetsnodene blir opprettet hver gang systemet starter, blir de lagret på et devtmpfs filsystem (et virtuelt filsystem som ligger helt i systemminnet). Enhetsnoder krever ikke mye plass, så minnet som brukes er ubetydelig.

7.3.1. Historie

I februar 2000 ble et nytt filsystem kalt devfs flettet inn i 2.3.46-kjernen og ble gjort tilgjengelig i 2.4-serien med stabile kjerner. Selv om det var til stede i selve kjernekilden, mottok denne metoden for å lage enheter dynamisk aldri overveldende støtte fra kjerneutviklerne.

Hovedproblemet med tilnærmingen som ble benyttet av devfs var måten den håndterte enhetsgjenkjenning, oppretting og navngivning på. Det sistnevnte problemet, navnet på enhetsnodenavn, var kanskje det mest kritiske. Det er generelt akseptert at hvis enhetsnavn kan konfigureres, så skal enhetsnavn politikken være opp til en systemadministrator, og ikke pålagt dem av en spesielle utvikler. Devfs filsystemet led også av kjøreforhold som var iboende i utformingen, og som ikke kunne rettes uten en betydelig revisjon av kjernen. Den ble markert som avviklet i lang tid - på grunn av manglende vedlikehold - og ble til slutt fjernet fra kjernen i juni 2006.

Med utviklingen av det ustabile 2.5 kjernetreet, som senere ble utgitt som 2.6 serien av stabile kjerner, ble det et nytt virtuelt filsystem kalt sysfs. Jobben til sysfs er å eksportere en visning av systemets maskinvarekonfigurasjon til brukerområdeprosesser. Med denne brukerområdet-synlige representasjonen ble muligheten for å utvikle en brukerstedserstatning for devfs mye mer realistisk.

7.3.2. Udev Implementering

7.3.2.1. Sysfs

Sysfs filsystemet ble nevnt kort ovenfor. Man kan lure på hvordan sysfs vet om enhetene som er tilstede i et system og hvilke enhetsnumre som skal brukes til dem. Drivere som er kompilert i kjernen, registrerer objektene sine direkte med en sysfs (devtmpfs internt) slik de oppdages av kjernen. For drivere som er kompilert som moduler, vil denne registreringen skje når modulen lastes inn. Når sysfs filsystemet er montert (på /sys), er data som driverne registrerer med sysfs tilgjengelig for brukerområdeprosesser og for utevd for behandling (inkludert modifikasjoner av enhetsnoder).

7.3.2.2. Oppretting av enhetsnode

Enhetsfiler opprettes av kjernen av devtmfps filsystemet. Enhver driver som ønsker å registrere en enhetsnode, vil gå gjennom devtmpfs (via driverkjernen) for å gjøre det. Når en devtmpfs forekomst er montert på /dev, blir enhetsnoden opprettet med et fast navn, tillatelser og eier.

Kort tid senere vil kjernen sende en hendelse til udevd. Basert på reglene som er spesifisert i filene i katalogene /etc/udev/rules.d, /lib/udev/rules.d og /run/udev/rules.d, vil udevd opprette flere symlenker til enhetsnoden, eller endre tillatelser, eier eller gruppe, eller endre den interne udevd databaseoppføringen (navnet) for det objektet.

Reglene i disse tre katalogene er nummererte og alle tre katalogene slås sammen. Hvis udevd ikke finner en regel for enheten den oppretter, vil den la tillatelsene og eierskapet ligge på det devtmpfs som ble brukt i utgangspunktet.

7.3.2.3. Modulinnlasting

Enhetsdrivere som er sammensatt som moduler, kan ha innebygde aliaser. Aliaser er synlige i utdataene fra modinfo programmet og er vanligvis relatert til busspesifikke identifikatorer for enheter som støttes av en modul. For eksempel støtter snd-fm801 driveren PCI enheter med leverandør-ID 0x1319 og enhets-ID 0x0801, og har et alias "pci: v00001319d00000801sv * sd * bc04sc01i *". For de fleste enheter eksporterer bussjåføren aliaset til sjåføren som vil håndtere enheten via sysfs. F.eks. Kan filen /sys/bus/pci/devices/0000:00:0d.0/modalias inneholde strengen “pci: v00001319d00000801sv00001319sd00001319bc04sc01i00”. Standardreglene som følger med Udev vil føre til at udevd kaller opp /sbin/modprobe med innholdet i MODALIAS uevent miljøvariabelen (som skal være det samme som innholdet i modalias filen i sysfs), og laster dermed alle moduler hvis alias stemmer overens denne strengen etter utvidelse av jokertegn.

I dette eksemplet betyr dette at i tillegg til snd-fm801, vil den foreldede (og uønskede) forte driveren lastes inn hvis den er tilgjengelig. Se nedenfor for hvordan lastingen av uønskede drivere kan forhindres.

Selve kjernen er også i stand til å laste inn moduler for nettverksprotokoller, filsystemer og NLS støtte på forespørsel.

7.3.2.4. Håndtering av hotpluggable/dynamiske enheter

Når du kobler til en enhet, for eksempel en USB spiller (Universal Serial Bus), gjenkjenner kjernen at enheten nå er koblet til og genererer en hendelse. Denne hendelsen håndteres deretter av udevd som beskrevet ovenfor.

7.3.3. Problemer med å laste inn moduler og lage enheter

Det er noen få mulige problemer når det gjelder automatisk oppretting av enhetsnoder.

7.3.3.1. En kjernemodul lastes ikke inn automatisk

Udev vil bare laste inn en modul hvis den har et busspesifikt alias og bussdriveren eksporterer de nødvendige aliasene riktig til sysfs. I andre tilfeller bør man ordne modulinnlasting på annen måte. Med Linux-5.5.3 er Udev kjent for å laste riktig skrevet drivere for INPUT-, IDE-, PCI-, USB-, SCSI-, SERIO- og FireWire-enheter.

For å avgjøre om enhetsdriveren du trenger har nødvendig støtte for Udev, kjør modinfo med modulnavnet som argument. Prøv nå å finne enhetsmappen under /sys/bus og sjekk om det er en modalias fil der.

Hvis modalias filen finnes i sysfs, støtter driveren enheten og kan snakke med den direkte, men har ikke aliaset, det er en feil i driveren. Last inn driveren uten hjelp fra Udev og forvent at problemet blir løst senere.

Hvis det ikke er noen modalias filer i den aktuelle katalogen under /sys/bus, betyr dette at kjerneutviklerne ennå ikke har lagt til modalias støtte til denne busstypen. Med Linux-5.5.3 er dette tilfelle med ISA busser. Forvent at dette problemet blir løst i senere kjerneversjoner.

Udev er ikke ment å laste inn “innpakkede” (“wrapper”) drivere som snd-pcm-oss og drivere som ikke er maskinvare, for eksempel loop i det hele tatt.

7.3.3.2. En kjernemodul lastes ikke automatisk, og Udev er ikke ment å laste den

Hvis "innpaknings"  modulen bare forbedrer funksjonaliteten som tilbys av en annen modul (f.eks. Snd-pcm-oss forbedrer funksjonaliteten til snd-pcm ved å gjøre lydkortene tilgjengelige for OSS-applikasjoner), konfigurerer du modprobe for å laste inn innpakningen etter at Udev har lastet inn den innpakkede modulen. For å gjøre dette, legg til en "softdep" linje i den tilsvarende /etc/modprobe.d/<filnavn> .conf filen. For eksempel:

softdep snd-pcm post: snd-pcm-oss

Merk at kommandoen “softdep” også tillater pre: avhengigheter, eller en blanding av både pre: og post:. Se modprobe.d (5) manual side for mer informasjon om “softdep” syntaks og funksjoner.

Hvis den aktuelle modulen ikke er en innpakning og er nyttig i seg selv, konfigurerer du modulets bootscript for å laste denne modulen på systemstart. For å gjøre dette, legg til modulnavnet i filen /etc/sysconfig/modules på en egen linje. Dette fungerer også for innpakkede moduler, men er i så fall ikke optimalt.

7.3.3.3. Udev laster inn noen uønskede moduler

Enten ikke bygg modulen, eller svarteliste den i en /etc/modprobe.d/blacklist.conf fil som gjort med forte modulen i eksemplet nedenfor:

blacklist forte

Svartelistede moduler kan fortsatt lastes manuelt med den eksplisitte modprobe kommandoen.

7.3.3.4. Udev oppretter en enhet feil, eller lager en feil symlenke

Dette skjer vanligvis hvis en regel uventet samsvarer med en enhet. For eksempel kan en dårlig skrevet regel matche både en SCSI-disk (som ønsket) og den tilsvarende SCSI-generiske enheten (feil) av leverandøren. Finn den fornærmende regelen og gjør den mer spesifikk, ved hjelp av udevadm info kommandoen.

7.3.3.5. Udev regelen fungerer upålitelig

Dette kan være en annen manifestasjon av det forrige problemet. Hvis ikke, og regelen din bruker sysfs attributter, kan det være et problem med kjernetiming, som skal løses i senere kjerner. Foreløpig kan du omgå det ved å lage en regel som venter på det brukte sysfs attributtet og legge den til i /etc/udev/rules.d/10-wait_for_sysfs.rules filen (opprett denne filen hvis den ikke eksisterer). Gi beskjed til LFS Development listen hvis du gjør det, og det hjelper.

7.3.3.6. Udev oppretter ikke en enhet

Ytterligere tekst antar at driveren er innebygd statisk i kjernen eller allerede er lastet inn som en modul, og at du allerede har sjekket at Udev ikke lager en feil navngitt enhet.

Udev har ingen informasjon som trengs for å opprette en enhetsnode hvis en kjernedriver ikke eksporterer dataene til sysfs. Dette er vanligst med tredjepartsdrivere utenfor kjernetreet. Opprett en statisk enhetsnode i /lib/udev/devices med riktige større/mindre tall (se filen devices.txt i kjernedokumentasjonen eller dokumentasjonen fra tredjeparts driverleverandør). Den statiske enhetsnoden blir kopiert til /dev av udev.

7.3.3.7. Navnerekkefølgen på enheten endres tilfeldig etter omstart

Dette skyldes det faktum at Udev, etter design, håndterer hendelser og laster moduler parallelt, og dermed i en uforutsigbar rekkefølge. Dette vil aldri bli "løst". Du bør ikke stole på at kjernenhetens navn er stabile. I stedet lager du dine egne regler som lager symlinker med stabile navn basert på noen stabile attributter til enheten, for eksempel et serienummer eller utdata fra forskjellige * _id-verktøy installert av Udev. Se avsnitt 7.4. “Administrere enheter” og seksjon 7.5. “Generell nettverkskonfigurasjon” for eksempler.

7.3.4. Nyttig lesing

Ytterligere nyttig dokumentasjon er tilgjengelig på følgende nettsteder:

Forrige Hjem Neste