Det afhænger af den bestemte grænseflade, men den generelle idé er ofte den samme og involverer normalt IKKE adskillelse af driveren. Årsagen er, at demonteringsmetoden til reverse engineering ikke betragtes som lovlig i alle jurisdiktioner. Her er de sædvanlige trin:

1. Kontakt producenten for at få de nødvendige oplysninger

Den mest direkte tilgang er naturligvis også den nemmeste, hvis den lykkes. Nogle producenter er mere samarbejdsvillige end andre. For nogle typer enheder, selvom producenten af ​​en enhed ikke er samarbejdsvillig, er producenten af ​​større chips på enheden nogle gange villige til at dele nogle oplysninger, og det kan hjælpe.

2. Få generel information om enheden ved observation

En masse information kan fås blot ved observation. For eksempel, hvad er hovedkomponenterne i enheden? Kan vi slå delnumre op og finde datablad til dem? Er denne version n + 1 og findes der allerede en version n driver til Linux? Giver manualen eller Windows-driverens brugergrænseflade vigtige spor om registre, indstillinger eller funktioner? Understøtter Windows-driveren flere enheder? Dette kan være en indikation af, at enhederne muligvis ligner hinanden, og hvis der allerede er en Linux-driver til en af ​​dem, kan det hjælpe.

3. Optag kommunikation med enheden til analyse

For nogle enheder, såsom serielle porte eller USB, er det normalt ret ligetil at fange kommunikationen mellem enhedsdriveren og enheden. (Se Sådan reverse engineer simpel USB-enhed [windows -> linux]) Optagelse af kommunikation til videokort kan ske på et par måder. En måde, det kan gøres på, er ved at bruge en proprietær Linux-driver og derefter opfange opfordringer til det, som med værktøjet REnouveau. Deling af data er vigtigt, og det er en af ​​grundene til, at så mange drivere er blevet skrevet med succes til Linux. En af de store styrker ved open source-samfundet er, at der er mennesker over hele verden, der kan og samarbejder med en sådan indsats.

4. Forsøg på at duplikere kommunikationen under Linux

Dette er et spørgsmål om at skrive kode og prøve resultatet. Fordi Linux allerede har et stort sæt drivere, er det ofte nemmest at starte med noget lignende og ændre det. Da alt er open source, er tinkering ikke kun tilladt men opmuntret! På andre enheder end videokort kan man ofte skrive brugerrumskode for at forsøge at udøve enheden og for at indsamle data og prøve eksperimenter. I sidste ende er en ægte driver skrevet, ideelt som et kernemodul, for at tillade aflæsning og genindlæsning. Dette fremskynder udviklingscyklussen over at skulle genstarte efter enhver driverændring (jeg kigger på DU , Windows!)

5. Test grundigt

Test og bugfixing er generelt vigtigt for open source-software, og det gælder bestemt for enhedsdrivere såvel som alt andet. For det første, for at blive inkluderet i kernen, ser andre udviklere på koden i en undertiden brutal, men altid anvendelig proces kaldet code review. Andre erfarne udviklere ser på kildekoden og påpeger svagheder i koden, mangler i antagelser og endda skrivefejl i kommentarer og formateringsproblemer. Når nok folk har gjort det, prøver folk med den aktuelle enhed faktisk det på deres hardware og rapporterer fejl eller uregelmæssigheder. Dette viser ofte problemer som versionforskelle (f.eks. Var der flere versioner af den fysiske enhed, men alle solgt som den samme ting) og enhedskonflikter (både enhed A og enhed B fungerer godt individuelt, men mislykkes, når begge er tilsluttet).

I sidste ende er resultatet en skinnende ny fejlfri open source-driver, som alle kan bruge. (Eller det er alligevel målet!)