Jaderné noviny – 17. 6. 2009 (diskuse)

[Jan Grmela]

Byla přidána podpora pro hostitelské řadiče USB3.0/xHCI, žádný však ještě není k dispozici.

Jsem rád, že je Linux připraven i když skutečných zařízení se stejně dočkáme tak nejdřív za rok.

[Petr Tomášek]

To by mě teda zajímalo, jak takovou věc testovali :=ooo

[cronin]

Naco? Ved nie je nikto, komu by nefungovala.

[Nikola Ciprich]

čipová sada AMD r60 čipová sada Intel IGDNG

asi chybi odrazka. jinak jako vzdy skvele pocteni!

[Robert Krátký]

asi chybi odrazka

Dík, opraveno.

[cronin]

V casti "Mezi změny viditelné vývojářům jádra patří:" su niektore odrazky zdvojene. Presnejsie chyba lomka v uzatvarajucom elemente li.

[cronin]

Tie navrhove vzory su zaujimave; skoda ze nabuduce uz ma byt posledna cast.

Nejak nerozumiem tomu konceptu "kotvy"; nemate niekto nejaky link kde je opisany?

[frr]

Představte si, že máte struct, který obsahuje několik proměnných (memberů) různých typů - například další vnořené structy.

No a dostanete se ve zdrojáku do situace, kdy máte pointer na ten vnořený struct, a potřebujete zjistit pointer na ten větší struct, který ho obaluje. Vlastně jde o to, zjistit ofset vnořeného structu v tom obalovém structu (operace na úrovni statických typů, čili ta informace je k dispozici už při kompilaci) a odečíst ho od známého pointeru na vnořený struct.

Všiml jsem si, že to kernel umí řešit nějakými makry - patrně zmiňovaným container_of().

Omlouvám se, pokud tohle všechno je jasné Dál to z hlavy dopodrobna neznám. Čili nevím přesně, jak "kotva" funguje.

Tuším že jsem to viděl v klasické kernelové knihovničce pro vytváření "spojových seznamů", kde "struct list_head" je vnořený do Vašeho uživatelského structu. No a při procházení seznamem pracujete s pointery na ten vnořený list_head, ale cílem je, dostat pointer na ten Váš uživatelský struct.

[cronin]

Vdaka, uz tomu zacinam rozumiet. Pre rigidneho Javistu ako ja to vo vseobecnosti vyzera ako porusenie zapuzdrenia; na druhej strane je zjavne, ze na urcite typy pouzitia je to ucinny pristup.

[alblaho]

Může mi někdo vysvětlit, co je to ta kotva? V životě jsem o žádné neslyše.

[Ladicek]

No, pokud tomu dobře rozumím (Luk o tom ve svojí knížce o jádře mluví taky), je to asi takhle:

Obvyklá implementace spojového seznamu staví na struktuře, řekněme, ListNode, která vypadá zhruba takhle (pseudokód!):

class ListNode<T> {
  ListNode<T> next;
  T data;
}

Šikulové od jádra to převrátili vzhůru nohama a vymysleli asi tohle:

class ListNode {
  ListNode next;
}

class MyData {
  ...
  ListNode node;
}

Implementace seznamu pracuje s ListNode, ale navenek umí poskytnout přímo objekty dat. Představuju si to asi takhle nějak:

void forEach(ListNode head, {T -> void} callback) {
  ListNode curr = head;
  while (curr != null) {
    callback.invoke(CONTAINER_OF(curr)); // !!!
    curr = curr.next;
  }
}

MyData a = new MyData(...); a.node = new ListNode();
MyData b = new MyData(...); b.node = new ListNode(); b.node.next = a.node;

forEach(a) { MyData data -> ... }

Pochopitelně tohle je extrémně zjednodušené, ale myslím, že princip je správný. Pokud se pletu, někdo mne prosím opravte

[alblaho]

Hm, zajímavé. Asi si stáhnu zdrojáky a podívám se, jak je implementováno CONTAINER_OF, protože bych očekával, že ListNode by musel být vždy první field datové struktury (starý trik, používá mj. CSim). Jenže pak by struktura nemohla být ve více seznamech.

[alblaho]

Dětská slavnost:

/**
 * container_of - cast a member of a structure out to the containing structure
 * @ptr:	the pointer to the member.
 * @type:	the type of the container struct this is embedded in.
 * @member:	the name of the member within the struct.
 *
 */
#define container_of(ptr, type, member) ({			\
	const typeof( ((type *)0)->member ) *__mptr = (ptr);	\
	(type *)( (char *)__mptr - offsetof(type,member) );})

[danfis]

Šikulové od jádra to převrátili vzhůru nohama a vymysleli asi tohle: ...

To je proto, aby se mohlo vice techto vzoru pouzivat v jedne strukture (napriklad aby mohla byt struktura ve vice seznamech). Implementace dedicnosti (od jednoho predka) by mohla jednoduse vypadat nejak takhle:

struct parent { ... };
struct s {
    struct parent; // prvni prvek ve strukture
    ...
};

Na strukturu s pak muzes pouzivat vsechny funkce (samozrejme s pretypovanim - coz ale za tebe muze delat nejake makro), ktere lze pouzit na strukturu parent bez pouziti maker typu container_of() nebo offset().

[Ladicek]

To převrátili vzhůru nohama nemělo znít nijak pejorativně, je to výborný nápad (pro jaderné účely). Stejně tak jedna z implementací wait-free hashovací tabulky je vlastně postavená na hlavu (nejde o indexované seznamy, ale indexy do seznamu)

[Ladicek]

Teď koukám, že kecám, ta hashovací tabulka, kterou jsem zmiňoval, je jenom lock-free. Ale stejně je to pěkný nápad

[kralyk z abclinuxu]

Na strukturu s pak muzes pouzivat vsechny funkce (samozrejme s pretypovanim - coz ale za tebe muze delat nejake makro), ktere lze pouzit na strukturu parent

Tyvado tak to je fikaný, by mě nenapadlo, ale to skutečně tak je. Akorát musí člověk pamatovat, že je potřeba alokovat/uvolnit víc paměti pro potomka, aby to nezatejkalo...

[Laco]

To je taka ta vec ktoru maju lode a ked sa chcu urzat na mieste vypustia kotvu...

Keby si furt nieco nekopiloval a nepisal v terminale a namiesto to si dal Vistu, mal by si cas aj na vseobecne vzdelavanie :p

[Pev]

bylo začleněny

[geebranz]

Software update

metalbuildingstylertx.com