Jockey

Jockey ay isang kasangkapan para sa pag-install ang driver ng hardware third-party.
Jockey nagbibigay ng imprastraktura at ang user interface para sa paghahanap at pag-install ng mga third-party ng driver kung saan ay naaangkop sa computer. Kabilang dito ang driver kung saan ay idinagdag o na-update matapos ang release ng isang pamamahagi, o ang driver kung saan ay hindi maaaring isama sa pamamahagi sa iba't ibang dahilan (CD space limitasyon, ang mga problema sa paglilisensya, atbp.)
Ang isang karaniwang pagkakataon ng paggamit ay nagbibigay ng isang friendly at semiautomatic na paraan upang i-install ang mga driver para sa mga bagong hardware na kung saan ang mga kasalukuyang release pamamahagi ay hindi pa sinusuportahan, o i-install ang Nvidia at ATI fglrx X.org driver.
Jockey ay idinisenyo upang maging distribution agnostic at matupad ang mga pangangailangan ng iba't ibang mga distribusyon, driver vendor, at integrators system. Ito ay dinisenyo at binuo sa loob ng LinuxFoundation driver backports workgroup.
Operation
Sa umpisa, ang Jockey backend probes ang sistema para sa mga magagamit na hardware. Ito ay maaaring mangyari sa iba't ibang paraan, na kasalukuyang ipinapatupad ay & nbsp; scanning / sys para modaliases. Sa hinaharap ito ay binalak upang magdagdag ng higit pang mga paraan, tulad sa pagtanong ukol sa mga tasa para napansin printer na hindi magkaroon ng isang driver. & Nbsp; Pamamaraan ng pagtuklas ay idinagdag bilang kinakailangan sa pamamagitan ng mga bahagi na mga vendor at distribusyon. Ang hanay ng mga magagamit na hardware ay kinakatawan bilang "HardwareID" na mga bagay (na maaaring kumatawan sa anumang bagay na natatanging nagpapakilala sa isang piraso ng hardware, tulad ng isang vendor / produkto ID, isang modalias, o isang printer identification string).
Para sa bawat hardware ID, isang set ng mga driver database (pagkakaton ng DriverDB) ay na-query para sa magagamit na mga driver. Sa ngayon, ang tanging umiiral na pagpapatupad ay LocalKernelModulesDriverDB, na gumagamit ng standard na Linux kernel modules.alias mapa sa modaliases sa kernel modules mapa. Sa malapit na hinaharap plano namin na magdagdag ng isa pang pagpapatupad na tanong ng isang online na database driver pati na rin. Ang DriverDBs anyo ang hanay ng HardwareIDs sa isang set ng DriverIDs.
A DriverID kumakatawan sa lahat ng mga kinakailangang metadata tungkol sa isang driver, tulad ng:
* Driver class (kernel module, driver printer, package, X.org graphics driver, firmware, atbp)
* Pangalan ng handler class (tingnan sa ibaba)
* Lokasyon ng mga driver (repository, pangalan ng package, posibleng sha1 at iba pang checksums, lagda)
* Driver tiyak na mga parameter (arbitrary type / halaga ng mga pares na nauunawaan ang mga handler)
Lahat ng mga driver sa pamamagitan ng hawakan Jockey kailangan na encapsulated sa pamamagitan ng isang subclass ng "Handler". Isang handler halimbawa ay nagbibigay ng isang hook para arbitrary code na pangangailangan upang patakbuhin upang lubos na i-install ng driver. Jockey na nagbibigay handler pagpapatupad para sa mga karaniwang mga kaso tulad ng kernel modules, kernel module firmware, driver X.org, mga grupo ng mga driver, etc. Ang karamihan sa mga driver ay gamitin parameterized pagkakataon ng mga default na handler, pero ang driver kung saan kailangan mo ng ilang mga mas sopistikadong mga lokal na maaari barko configuration kanilang sariling handler subclass at idagdag ang mga kinakailangang code.
Istraktura
Ang bulk ng trabaho Jockey (detection hardware, database ng mga tanong ng driver, installation package, at iba pa) ay ginagawa sa pamamagitan ng isang UI independent backend na nagbibigay ng pag-andar nito sa loob ng sistema ng D-bus. Access ay kontrolado ng mga pribilehiyo PolicyKit (tingnan backend / com.ubuntu.devicedriver.policy.in para sa detalye); sa pamamagitan ng default, ang lahat ng mga user ay maaaring gawin ang mga lokal na mga query sa katayuan ng aparato driver, lahat ng lokal na mga user ay maaaring mag-trigger ng isang remote query database driver, at ang tunay na pag-install / pagtanggal ng mga driver ay limitado sa mga system administrator.
Ang iba't ibang mga user interface (GTK, at KDE, at parehong magbigay ng isang cli rin) tumakbo sa normal na mga pribilehiyo ng gumagamit at nagbibigay lamang ng isang tao na friendly at internationalized pagtatanghal / UI ng backend na serbisyo. Hindi sila naglalaman ng anumang mga driver na lohika.
Adaptasyon Jockey sa isang pamamahagi ng Linux
Jockey ay maingat na isinulat upang hindi maging tiyak sa anumang pamamahagi ng Linux. Lahat ng mga operasyon tiyak OS / distro ay encapsulated sa "OSLib" class, kung saan kailangang subclassed at ipinatupad sa pamamagitan ng mga distribusyon ng Linux. Karamihan sa mga pamamaraan ay mayroon upstream isang makatwirang default pagpapatupad, ngunit ang ilan ay lamang likas distro tiyak na (paghahanap para sa "NotImplementedError" upang mahanap ang mga).
Ito minimizes ang porting pagsisikap ng mga distributor habang napananatili ang posibilidad na gumawa ng mga pagbabago sa isang sentral na lugar.
Ang abstract OSLib klase ay lubusan dokumentado, at doon ay mayroon na ng isang sangay ng Ubuntu [3], at ang mga test suite ay may isang dummy pagpapatupad (tingnan pagsusulit / sandbox.py). Ang mga ito ay dapat magkasiya upang ipatupad Jockey para sa iba pang mga distribusyon na rin

Ano ang bago sa release na ito.

• Ang bersyon na ito ay pag-aayos ng isang tonelada ng mga bug, kabilang ang lahat ng mga na kung saan ay kasalukuyang pinili bilang blockers para sa huling 0.5 release.
• Hindi kailangang mga bagong tampok.

Ano ang bago sa bersyon 0.5 Alpha 1:

• Ito ang unang preview ng mga paparating na 0.5 release na kung saan naka-focus sa isang malaking disenyo ng maingat na pagsusuri upang mapabuti ang maaaring dalhin, suporta para sa printer detection, driver ng printer mula openprinting.org, isang interface D-bus para sa mga driver lookup para sa mga desktop application, at isang refurbished GTK user interface.