AbcLinuxu:/ Články / Jaderné noviny 259

Štítky: C, C++, e-mail, Flash, hardware, KDE, kernel, komunikace, Linux, Microsoft, ovladače, patch, programování, prohlížeče, USB, Windows

Jaderné noviny 259

25. 5. 2004 | Robert Krátký | Jaderné noviny | 5557×

Dokumentování KGDB. Budoucnost dnotify. Status Serial ATA (SATA). Ovladač pro RNDIS USB a Picture Transfer Protocol. Vydána verze 1.1.0 libsysfs.

Do konference přišlo celkem 1946 emailů, nejvíce jich poslali Paul Jackson, Andrew Morton a Jeff Garzik.

Dokumentování KGDB, 10 e-mailů

19. bře - 31. bře

Tom Rini napsal:

Toto je pokus o dokumentaci rozličných funkcí specifických jednotlivým architekturám, které jsou součástí KGDB. Je to několik volitelných funkcí závisejících na daném hardwaru - pro ty jsou nastaveny výchozí hodnoty. Jsou však i funkce, které implementovány být musí, a pro které žádné výchozí hodnoty nastaveny nejsou.

Vyžadované funkce:

int kgdb_arch_handle_exception(int vector, int signo, int err_code, char *InBuffer, char *outBuffer, struct pt_regs *regs)
Tato funkce MUSÍ mít na starosti pakety 'c' a 's' příkazů a rovněž pakety pro nastavení/odstranění hardwarového brejkpointu, byl-li použit.

void regs_to_gdb_regs(unsigned long *gdb_regs, struct pt_regs *regs)
Převedení ptrace regs v regs do toho, co GDB očekává jako registry v gdb_regs.

void sleeping_thread_to_gdb_regs(unsigned long *gdb_regs, struct task_struct *p)
Jako regs_to_gdb_regs, až na to, že proces v p spí, takže nemůžeme získat tolik informací.

void gdb_regs_to_regs(unsigned long *gdb_regs, struct pt_regs *regs)
Převedení GDB regs v gdb_regs do ptrace regs, na které je ukazováno v regs.

Volitelné funkce:

int kgdb_arch_init(void) :
Tato funkce zajišťuje inicializaci všech hooků jednotlivých architektur. Existuje-li vhodný výstupní ovladač, lze na něj teď nasměrovat kgdb_serial.

void kgdb_printexceptioninfo(int exceptionNo, int errorcode, char *buffer)
Zapsání do bufferu a informace o proběhlé výjimce, které lze získat z exceptionNo a errorcode.

void kgdb_disable_hw_debug(struct pt_regs *regs)
Zákaz hardwarového debuggování zatímco jsme v kgdb.

void kgdb_correct_hw_break(void)
Hook umožňující změnu hardwarového brejkpointu, volaný po single krok (s) nebo pokračovacím (continue) (c) paketu a tehdy, když se chystáme nechat kernel pokračovat v běhu.

void kgdb_post_master_code(struct pt_regs *regs, int eVector, int err_code)
Uloží vektor a chybu pro pozdější referenci.

void kgdb_shadowinfo(struct pt_regs *regs, char *buffer, unsigned threadid)
struct task_struct *kgdb_get_shadow_thread(struct pt_regs *regs, int threadid)
struct pt_regs *kgdb_shadow_regs(struct pt_regs *regs, int threadid)
Máme-li stínový thread (určený nastavením kgdb_ops->shadowth = 1), jsou tyto funkce potřeba k vracení informací o takovém threadu.

Amit S. Kale by tyto informace rád viděl přidané do zdrojových kódů a kromě toho doplnil: Dodatek: stínové thready jsou potřeba k poskytování informací, které nelze získat pomocí gdb. Např. backtracy za entrypointy přerušení, které nelze získat bez debuggovacích informací o kódu entrypointů přerušení.

Budoucnost dnotify, 11 e-mailů

24. bře - 26. bře

Rudiger Klaehn napsal:

Pracoval jsem na vylepšení dnotify, aby fungovalo rekurzivně a ukládalo informace o tom, co přesně se změnilo.

Můj současný kód najdete na: <http://www.lambda-computing.com/~rudi/dnotify/>

Při čtení konference jsem získal dojem, že lidé všeobecně souhlasí s tím, že současný mechanismus dnotify je méně než vyhovující, a že by se s tím něco mělo dělat. Je to tak?

Moje stávající implementace mechanismus dnotify vylepšuje, ale je zpětně kompatibilní se starým mechanismem. To je samozřejmě méně rušivý přístup, ale také ne moc optimální.

Během offline diskuze přišlo na přetřes i to, jestli by nebylo lepší dnotify nahradit zcela novým mechanismem - například zláštním netlink socketem. Vzhledem k tomu, že většina uživatelských programů (např. KDE a Gnome) nepoužívá dnotify přímo, nýbrž přes FAM démona, nutné změny v uživatelských aplikacích by nebyly tak velké.

Jak se na to díváte? Vylepšit nebo nahradit?

Pár lidí přispělo svým názorem na některé z funkcí a diskuze se točila převážně kolem technických problémů, které navržená řešení představují.

Po nějaké době do toho rozhodným způsobem vstoupl Alexander Viro:

"Doktore, když to dělám, bolí to"

Vážně, dnotify je špatné v mnoha ohledech. Počínaje základní premisou - že uživatelské programy mohou udržovat stromový obraz adresářů na základě upozornění. Už podle definice je to problémové, takže všechny pokusy využít to pro "bezpečnostní vylepšení" jsou nesmysly. Což nám ponechává souborové mrzatéry a jim podobné.

Snaha sledovat "aliasy" v uživatelském prostředí je beznadějně problémová; připojování/odpojování není ani v dohledu; různí uživatelé mohou vidět různé části stromu nebo, když už jsme u toho, úplně jiné stromy; tyhle hnusárny jsou DDoS pro každý server, který exportuje jakýkoliv druh síťového souborového systému mnoha klientům - obzvláště pokud chcete upozornění o celém stromu.

Jinými slovy, celá ta idea je od základu chybná a podle mého názoru je jediným skutečným řešením pokusit se přijít se slušným uživatelským rozhraním, které by poskytovalo to, k čemu jsou souborové manažery ve skutečnosti používány.

Rudiger odpověděl: Souborové manažery jsou pouze jedním z využití pokročilého mechanismu pro upozorňování na změny souborů. Existuje mnoho daleko zajímavějších aplikací. Pro file manažery je stávající dnotify mechanismus postačující. Diskuze však již nepokračovala.

Status Serial ATA (SATA), 2 e-maily

25. bře

Fabian Fenaut se zeptal na stav ovladače libata, především, jestli je stále považovaný za ALFA kód; a Jeff Garzik odpověděl:

Vzhledem k mé nedávné práci na odstraňování chyb (a rozlišení některých problémů na chyby platformy, nikoliv libata), bude ovladač Silicon Image beta a označení CONFIG_BROKEN bude zrušeno, jakmile vyjde jádro 2.6.5.

S posledními patchi bych řekl, že status sata_sil je už také "beta".

Ovladač pro RNDIS USB a Picture Transfer Protocol, 20 e-mailů

25. bře - 30. bře

Robert Schwebel napsal:

Konečně máme ovladač pro RNDIS USB - viz připojený patch oproti aktuálnímu stromu gadget-2.4 BK. Nemělo by být moc těžké to portovat na 2.6.

Ten patch poskytuje podporu pro RNDIS protokol Microsoftu do standardního g_ether ovladače. Díky tomu je možné připojit linuxové USB zařízení k jakémukoliv stroji se standardními Windows a <*BINGO!*> na straně Windows je nové USB síťové rozhraní, na kterém lze komunikovat pomocí TCP/IP :-) .

Bohužel, ačkoliv s originálním Microsoft ovladačem to funguje, na straně Windows budete potřebovat inf soubor; šablonu lze stáhnout přímo od M$.

Díky Auerswald GmbH za sponzorování této práce!

David Brownell byl nadšený a dodal: Osobně bych byl radši, kdyby Microsoft začal používat nezávislé protokoly místo nucení zbytku odvětví k adopci MSFT věcí... kupodivu nikoho na toto téma neposlechli. Ach jo ;). David Woodhouse se zeptal: Vymysleli už (nebo někdo jiný) 'file systémové' USB zařízení? Exportování souborových systémů a předstírání, že jsou to bloková zařízení moc užitečné totiž není. David odpověděl:

Existuje filesystémový protocol používaný mnoha digitálními fotoaparáty, který není závislý na daném přístroji. Ani na MSFT.

Originální název je "Picture Transfer Protocol" (PTP) a je to ve skutečnosti spíše vzdálený hierarchický filesystémový protokol... s kanálem pro události (hodí se pro "nový snímek" nebo "vložena flash paměť") a určitými vestavěnými vyhledávacími schopnostmi ("jaké máš JPG"). Nejpodivnější vlastností je možnost uchovávat označení typu souboru, což vlastně ani tak moc bizarní není.

Podobně jako u RNDIS a USB Mass Storage předpokládám, že podpora PTP je součástí MS-Windows někdy od Win2K. Takže ovladač pro PTP pro Linux by byl pravděpodobně užitečným počinem.

Don Reid řekl:

Host ovladač "USB PTP Storage" by byl také fajn. Nejprve jako obecné rozhraní pro fotoaparáty, potom pro přístup k zařízení s PTP rozhraním.

(Řekněte mi, prosím, že už to existuje a já budu tak rád, že se ani nebudu cítit trapně :-) .)

Mám PTP foťák a takový ovladač bych s potěšením otestoval. Nemohu říct, že bych měl čas to napsat.

David odpověděl: Už jsou dokonce dva. Oba jsou to uživatelské ovladače. "gPhoto2" a "jPhoto". Autor jPhoto (moi) neměl čas ten kód aktualizovat už věky. Ale Don reagoval:

To jsou aplikace, ne rozhraní souborového systému jako USB Mass Storage. Chci si připojit filesystém foťáku nebo jiného zařízení a přistupovat k němu z jakéhokoliv programu, ne spouštět samostatnou aplikaci pro stažení obrázků.

Proč vytvářet aplikaci výhradně jako rozhraní pro foťák místo použití vašeho oblíbeného prohlížeče obrázků?

David odpověděl: Základní odpovědí na tvou otázku je pravděpodobně to, že nikdo zatím nenapsal, nebo přinejmenším neposlal, PTP klienta nebo server pro linuxový kernel.