Jockey

Jockey is 'n instrument vir die installering van derde party hardeware bestuurders.
Jokkie verskaf die infrastruktuur en die gebruikerskoppelvlak vir die vind van en die installering van derde party bestuurders wat van toepassing is op die rekenaar is. Dit sluit bestuurders wat bygevoeg of bygewerk ná die vrystelling van 'n verdeling, of bestuurders wat nie kan ingesluit word in die verspreiding vir verskeie redes (CD ruimte beperking, lisensiëring probleme, ens.)
'N gemeenskaplike gebruik geval is die verskaffing van 'n vriendelike en semiautomatic manier om bestuurders vir nuwe hardeware wat die huidige verspreiding release nog nie ondersteun, of Nvidia en ATI fglrx X.org bestuurders te installeer.
Jokkie is ontwerp om die verspreiding agnostikus wees en voldoen aan die behoefte van die verskillende verdelings bestuurder verkopers, en die stelsel integrators. Dit is ontwerp en ontwikkel binne die LinuxFoundation bestuurder back ports werkgroep.
Operation
By die begin, die Jockey backend probes die stelsel vir die beskikbare hardeware. Dit kan gebeur op verskeie maniere, tans geïmplementeer is & nbsp; skandering / sys vir modaliases. In die toekoms sal dit word beplan om meer metodes, soos die gebruik daarvan koppies vir bespeur drukkers wat nie 'n bestuurder & nbsp het nie voeg. Opsporing metodes sal bygevoeg word as wat nodig is deur komponent verskaffers en verdelings. Die stel van beskikbare hardeware verteenwoordig as "HardwareID" voorwerpe (wat enigiets wat uniek identifiseer 'n stukkie van die hardeware, soos 'n ondernemer / produk ID, 'n modalias, of 'n drukker identifikasie string kan verteenwoordig).
Vir elke hardeware ID, 'n stel van die bestuurder databasisse (gevalle van DriverDB) is bevraagteken vir beskikbare bestuurders. Op die oomblik is, is die enigste bestaande implementering is LocalKernelModulesDriverDB, wat die standaard Linux kernel modules.alias kaarte gebruik om modaliases modules kern karteer. In die nabye toekoms beplan ons om 'n ander implementering wat 'n aanlyn-bestuurder databasis navrae sowel by te voeg. Die DriverDBs die transformasie van die stel van HardwareIDs om 'n stel van DriverIDs.
A DriverID verteenwoordig al die nodige metadata oor 'n bestuurder, soos:
* Bestuurder klas (kern module, drukker drywer, pakket, X.org grafiese bestuurder, firmware, ens)
* Hanteerder klas naam (sien onder)
* Ligging van die bestuurder (repository, pakket naam, moontlik sha1 en ander checksums, handtekeninge)
* Bestuurder spesifieke parameters (arbitrêre tipe / waarde pare wat die hanteerder verstaan)
Alle bestuurders hanteer word deur Jockey moet vervat word deur 'n subklas van "Handler". A hanteerder byvoorbeeld bied 'n haak vir enige kode wat nodig het om te hardloop om 'n bestuurder ten volle te installeer. Jokkie bied reeds hanteerder implementering vir algemene gevalle soos kern modules, kern module firmware, X.org bestuurder, groepe van die bestuurders, ens Die oorgrote meerderheid van die bestuurders sal parameters gevalle van hierdie standaard hanteerders gebruik, maar bestuurders wat 'n paar meer gesofistikeerde plaaslike nodig opset kan skip hul eie hanteerder subklas en voeg die nodige kode.
Struktuur
Die grootste deel van Jockey se werk (hardeware opsporing, bestuurder databasis navrae, pakket installasie, ens) word gedoen deur 'n onafhanklike UI backend wat sy funksies bied oor die stelsel D-BUS. Toegang word beheer deur PolicyKit voorregte (sien backend / com.ubuntu.devicedriver.policy.in vir besonderhede); by verstek, kan alle gebruikers plaaslike status toestelaandrywer navrae te doen, kan al die plaaslike gebruikers 'n afgeleë bestuurder databasis navraag aktiveer, en eintlik die installering / verwydering bestuurders is beperk tot die stelsel administrateurs.
Die verskillende gebruikerkoppelvlakke (GTK en KDE, en albei bied 'n CLI sowel) hardloop met 'n normale gebruiker voorregte en net bied 'n menslike vriendelik en die internasionale aanbieding / UI van die backend dienste. Hulle het nie die bestuurder logika bevat.
Aanpassing Jockey om 'n Linux verspreiding
Jokkie versigtig geskryf om nie spesifiek na 'n Linux verspreiding wees. Alle OS / distro spesifieke bedrywighede vervat in die "OSLib" klas, wat moet subclassed en geïmplementeer deur die Linux verspreidings. Die meeste metodes het reeds 'n redelike standaard implementering stroomop, maar sommige is net inherent distro spesifieke (soek vir "NotImplementedError" aan diegene te vind).
Dit verminder die porting pogings van verspreiders, terwyl die behoud van die moontlikheid om aanpassings in 'n sentrale plek te maak.
Die abstrakte OSLib klas deeglik gedokumenteer, en daar bestaan ​​reeds 'n tak vir Ubuntu [3], en die toets suite het 'n dummy implementering (sien toetse / sandbox.py). Dit moet voldoende om te implementeer Jockey vir ander uitkerings sowel

Wat is nuut in hierdie release:.

• Hierdie weergawe is 'n ton van foute, insluitend al die kinders wat op die oomblik is gekies as blokkers vir die finale 0,5 release.
• Dit maak nie nuwe funksies.

Wat is nuut in die weergawe 0,5 Alpha 1:

• Dit is die eerste voorskou van die komende 0,5 release wat fokus op 'n groot ontwerp opknapping om port, ondersteuning vir die opsporing drukker, printer drivers van openprinting.org, 'n D-Bus intervlakName vir die bestuurder lookup vir desktop applications, en 'n opgeknapte GTK gebruikerskoppelvlak te verbeter.