Microsoft zveřejnil na GitHubu zdrojové kódy MS-DOSu 4.0 pod licencí MIT. Ve stejném repozitáři se nacházejí i před lety zveřejněné zdrojové k kódy MS-DOSu 1.25 a 2.0.
Canonical vydal (email, blog, YouTube) Ubuntu 24.04 LTS Noble Numbat. Přehled novinek v poznámkách k vydání a také příspěvcích na blogu: novinky v desktopu a novinky v bezpečnosti. Vydány byly také oficiální deriváty Edubuntu, Kubuntu, Lubuntu, Ubuntu Budgie, Ubuntu Cinnamon, Ubuntu Kylin, Ubuntu MATE, Ubuntu Studio, Ubuntu Unity a Xubuntu. Jedná se o 10. LTS verzi.
Na YouTube je k dispozici videozáznam z včerejšího Czech Open Source Policy Forum 2024.
Fossil (Wikipedie) byl vydán ve verzi 2.24. Jedná se o distribuovaný systém správy verzí propojený se správou chyb, wiki stránek a blogů s integrovaným webovým rozhraním. Vše běží z jednoho jediného spustitelného souboru a uloženo je v SQLite databázi.
Byla vydána nová stabilní verze 6.7 webového prohlížeče Vivaldi (Wikipedie). Postavena je na Chromiu 124. Přehled novinek i s náhledy v příspěvku na blogu. Vypíchnout lze Spořič paměti (Memory Saver) automaticky hibernující karty, které nebyly nějakou dobu používány nebo vylepšené Odběry (Feed Reader).
OpenJS Foundation, oficiální projekt konsorcia Linux Foundation, oznámila vydání verze 22 otevřeného multiplatformního prostředí pro vývoj a běh síťových aplikací napsaných v JavaScriptu Node.js (Wikipedie). V říjnu se verze 22 stane novou aktivní LTS verzí. Podpora je plánována do dubna 2027.
Byla vydána verze 8.2 open source virtualizační platformy Proxmox VE (Proxmox Virtual Environment, Wikipedie) založené na Debianu. Přehled novinek v poznámkách k vydání a v informačním videu. Zdůrazněn je průvodce migrací hostů z VMware ESXi do Proxmoxu.
R (Wikipedie), programovací jazyk a prostředí určené pro statistickou analýzu dat a jejich grafické zobrazení, bylo vydáno ve verzi 4.4.0. Její kódové jméno je Puppy Cup.
IBM kupuje společnost HashiCorp (Terraform, Packer, Vault, Boundary, Consul, Nomad, Waypoint, Vagrant, …) za 6,4 miliardy dolarů, tj. 35 dolarů za akcii.
Byl vydán TrueNAS SCALE 24.04 “Dragonfish”. Přehled novinek této open source storage platformy postavené na Debianu v poznámkách k vydání.
Aktuální předverze je (24. 10. 2007) 2.6.24-rc1, vydaná 23. října. Linus k tomu poznamenal:
Tenhle patch je velký. Fakt velký. Nebude se vám chtít věřit, jak ukrutně obrovsky šíleně je velký. Možná si myslíte, že vás nic nepřekvapí, ale to jste ještě neviděli, jak velký ten patch je.
V textu níže najdete shrnutí toho, co bylo začleněno v posledním týdnu. Seznam patchů najdete v krátkém changelogu a všechny podrobnosti v douhém.
Od vydání -rc1 do hlavního git repozitáře žádné nové patche nepřibyly. V minulém týdnu také nevyšla žádná -mm verze.
Starší jádra: 2.6.20.21 bylo vydáno 17. října s několika desítkami patchů, včetně dvou bezpečnostních oprav. 2.6.16.56-rc1 vyšlo 20. října; obsahuje přibližně deset patchů a opět dvě bezpečnostní opravy.
mb() je nová lock_kernel(). Ach jo.
Takže *opravdu* nechci házet kameny v domě ze skla. Spíše naopak. Rád bych se nějakého skla zbavil a dal místo něj polstrování. Stejně všichni víme, že se tu více hodíme do polstrovaného pokoje než do skleněného domu.
Poznámka překl.: rčení "people who live in a glass house should not throw stones" [lidé, kteří žijí v domě ze skla, by neměli házet kameny] se používá přibližně ve smyslu "zameť si před vlastním prahem". Chce-li někdo po někom hodit šutrem (tj. něco mu vyčítat nebo ho za něco kritizovat), měl by si uvědomit, že pokud žije ve skleněném domě (tj. má také své chyby), mohl by mu jiný šutr zvenčí nadělat hodně nepříjemností.
Týden před vydáním 2.6.23 jsem přepnul do režimu opravování chyb. Částečně to způsobila ta idiotsky obrovská hromada věcí naplánovaných pro 2.6.24, částečně proto, že se potřebujeme soustředit na stabilizaci patchů pro 2.6.25 místo psaní nových věcí.
A částečně proto, abych dal najevo, že místo neustálého blbnutí s novými funkcemi bychom měli trávit více času testováním, kontrolou a opravováním chyb v současném kódu - stejně jako v tom, co bude současný kód za chvíli.
V tuto chvíli nevím o žádném běžně používaném hardwaru, který by v Linuxu nebyl podporován. A protože tito výrobci také ne, tak potřebuji pomoc od vás.
Na zářijovém kernel summitu prohlásil Andi Kleen, správce kódu architektur i386 a x86_64, že pokud dojde ke sloučení kódu do jedné architektury x86, nebude jej už dál spravovat. Vypadá to, že nezměnil názor; patch začleněný do 2.6.24 uvádí, že správci x86 budou Thomas Gleixner, Ingo Molnár a H. Peter Anvin. Kód x86 je zjevně v dobrých rukou, ale je škoda, že Andi končí; dlužíme mu hodně díků za tak dlouhou správu architektur, které používá většina z nás.
Začleňování nového kódu do 2.6.24 už skončilo; před vydáním -rc se do jádra dostalo přes 7000 patchů. Většina nových funkcí byla popsána minulý týden. Tohle je shrnutí patchů začleněných od té doby, počínaje změnami, kterých si všimnou i uživatelé:
Mezi změny viditelné pro vývojáře jádra patří:
Bylo přidáno pár nových operací s bity:
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.cz
int test_and_set_bit_lock(unsigned long nr, unsigned long *addr);
void clear_bit_unlock(unsigned long nr, unsigned long *addr);
void __clear_bit_unlock(unsigned long nr, unsigned long *addr);
Měly by být používány při vytváření jednobitových zámků; nepotřebují k funkci žádné další paměťové bariéry.
Teď začíná stabilizační období.
Obsluha přerušení je ta část ovladače zařízení, která má na starosti reagování na přerušení z hardwaru; přinejmenším by měla hardware zastavit a inicializovat zpracování, které je potřeba provést. Když Jonathan Corbet pracoval na druhém vydání knihy Linux Device Drivers, vypadal prototyp obsluhy přerušení takto:
void handler(int irq, void *dev_id, struct pt_regs *regs);
Vývojový proces jádra není zrovna šetrný vůči autorům knih, kteří obyčejně mívají rádi, když inkoust jejich výtvorů stihne alespoň uschnout, než začne být text zastaralý. Prototyp obsluhy přerušení se nenechal zahanbit a od vydání LDD2 se párkrát změnil, takže verze v 2.6.23 vypadá takto:
irqreturn_t handler(int irq, void *dev_id);
Během té doby přibyl k obsluze přerušení návratový typ (říká jádru, jestli už bylo přerušení zpracováno, nebo ne) a ubyl parametr týkající se registrů procesorů. Člověk by si myslel, že tohle rozhraní už si vytrpělo dost (společně s těmi, kdo jej dokumentují), ale vypadá to, že ani v blízké budoucnosti nedojde pokoje.
Jeff Garzik totiž navrhl odstranit z prototypu obsluhy přerušení parametr irq. Jen velmi málo obsluh přerušení tento parametr v současné době používá. A, jak to tak vypadá, většina těch zbývajících ho ve skutečnosti nepotřebuje; často používají číslo přerušení k identifikaci přerušujícího zařízení, ale právě pro ten účel už existuje ukazatel dev_id. I tak však bude začlenění tohoto patche vyžadovat dost práce, protože každá obsluha přerušení bude muset být zkontrolována a opravena.
Takže na to jde Jeff pomalu; není to patch určený k začlenění do 2.6.24. Než se do jádra dostane, bude aspoň čas na odstraňování parametru irq z ovladačů, což usnadní pozdější přechod na nové volání. Obsluhy, které IRQ číslo opravdu potřebují, mohou zavolat novou funkci get_irqfunc_irq(). Ale Jeff varuje: V každém z ovladačů, který používá get_irqfunc_irq(), nacházím spoustu chyb, takže bych se tím raději nejprve trpělivě probral a protlačil opravy do upstreamu. Docela dost oprav obsluh přerušení vycházejících z této práce už bylo posláno.
Eric Biederman se obává, že by převádění všech ovladačů bylo příliš náročné; navrhl vytvoření dvou různých rozhraní pro registraci a obsluhu přerušení, což by ovladačům, které opravdu potřebují IRQ číslo, umožnilo, aby ho i nadále dostávaly. Jeff si však je jistý, že další struktura nebude nutná. Thomas Gleixner by naopak byl rád, kdyby byly patche začleněny okamžitě, i když je téměř jisté, že tato sada patchů dostane na uzrání ještě jeden vývojový cyklus.
Alexej Dobrijan by mezitím chtěl dát do pořádku spinlock rozhraní, které by mělo fungovat s přerušeními [interrupt-safe spinlock interface]. Většina kódu, který vyžaduje spinlock při přerušeních, volá:
void spin_lock_irqsave(spinlock_t *lock, unsigned long flags);
Proměnnou flags používá kód (který je specifický pro jednotlivé architektury) k uložení stavu přerušení, jenž by mohl být potřeba, když je volána spin_unlock_irqrestore(). Problém s tímto rozhraním je v tom, že není moc typově bezpečné. Vývojáři někdy používají typ int místo unsigned long; nevygeneruje to žádné chyby a bude to fungovat na architektuře x86. Na některých jiných architekturách to však velmi nehezky vybouchne.
Alexej by tedy rád změnil flags na nový typ (irq_flags_t). Tento typ by byl z počátku definován jako unsigned long, takže by kvůli této změně neselhala kompilace. Byl by však označen, takže by utilita sparse mohla ukázat všechna místa, kde je spin_lock_irqsave() volána s nesprávným typem. Po dokončení změn by správci architektur mohli typ redefinovat na to, co na jednotlivých systémech funguje nejlépe - ať už by to byla struktura nebo jediný bajt.
Andrew Morton reagoval na patch takto:
Je pravda, že není moc pěkné, když pro tohle používáme unsigned long, místo abychom to korektně abstrahovali.
Přesto bych však byl rád, kdybychom pro zavedení irq_flags_t měli nějaký pořádný důvod. Prostě proto, že se mi nechce další dva roky zbytečně trávit zápasem s doslova tisícovkami patchů typu "převést-na-irq_flags_t", a také se mi nechce při stovkách kontrol kódu psát "prosím, používejte irq_flags_t".
Jako alternativa bylo navrženo, aby byla místo toho většina volání spin_lock_irqsave() změněna na spin_lock_irq(). Ta druhá verze totiž vypíná přerušení, aniž by ukládala předchozí stav; doprovodné volání spin_unlock_irq() pak přerušení zase povolí. S těmito funkcemi by to mohlo fungovat, ale pouze pokud by se vědělo, že přerušení nebudou v době volání spin_lock_irq() už vypnuta. Jinak by při volání spin_unlock_irq() hrozilo, že by se přerušení povolila v době, kdy si ještě jiná část jádra myslí, že jsou vypnuta. Výsledné zmatené chování považuje většina uživatelů za nežádoucí. Jinými slovy, spin_lock_irqsave() je bezpečnější rozhraní, a proto moc lidí s jeho odstraněním nesouhlasí. Představa toho, jak začínající vývojáři s dobrým úmyslem mění kód na spin_lock_irq(), aniž by doopravdy rozuměli širším souvislostem, je příliš nepříjemná.
A nakonec se diskutovalo o synchronize_irq(), což je kód, který ukazuje, jak těžké je zachytit souběhové situace [race conditions] na víceprocesorových systémech. Tato funkce:
void synchronize_irq(unsigned int irq);
je určena ke koordinaci akcí kódu ovladače (kódu pracujícího s přerušeními a toho ostatního). Základem je jednoduchá smyčka:
while (desc->status & IRQ_INPROGRESS)
cpu_relax();
synchronize_irq() tedy počká [busy-wait], dokud neví, že pro dané přerušení už neběží žádné obsluhy. Je to myšleno tak, že všechny obsluhy přerušení, které mohly běžet před voláním synchronize_irq(), budou už v okamžiku ukončení funkce dokončeny:
nějaký_důležitý_příznak = nová_hodnota;
synchronize_irq();
/* Kód, který závisí na obsluze IRQ, tu vidí novou_hodnotu */
Díky takovému kódu je jisté, že po zavolání synchronize_irq() uvidí každá obsluha přerušení novou_hodnotu - nebo si to aspoň lidé myslí.
Problém je v tom, že současné procesory klidně paměťové operace zpřeházejí, aby předešly zaseknutí linek [pipeline stalls] a zlepšily výkon. Podstatné je, že změna nějakého_důležitého_příznaku by mohla být přeřazena (opožděna), takže by ji ostatní procesory na systému viděly až po skončení synchronize_irq(). Během chvíle, kdy by změna nebyla viditelná, by synchronize_irq() nefungovalo - obsluha přerušení by mohla běžet, vidět starou hodnotu a způsobit zmatky. To je přesně ten druh tajemných souběhů, jež se vyskytují v jednom z miliardy případů, kvůli kterým mají vývojáři jádra špatné spaní.
Totiž, ve skutečnosti v noci nespí kvůli hackování na jádře a kafi, ale chápete, o co mi jde, že?
Benjamin Herrenschmidt se po objevení tohoto souběhu pokusil problém řešit pomocí paměťové bariéry. Po další diskuzi však začalo být jasné, že paměťová bariéra nebude stačit. Bariéry ovlivňují pořadí, ve kterém jsou operace viditelné, ale chybí-li odpovídající bariéry na dalším procesoru, tak nemohou zaručit, že bude v určitý čas pro takový procesor viditelná i konkrétní změna. To může zajistit jen zamykací operace, která vynutí synchronizaci mezi procesory - tedy operace, která se většinou používá k implementaci spinlocků.
Skutečné řešení nakonec asi bude patch od Linuse Torvaldse a Herberta Xu. Výše zmíněná smyčka while v nové verzi zůstává a běží dále, aniž by byly drženy nějaké zámky - držení zámku popisovače přerušení ve chvíli, kdy by ho mohl chtít subsystém přerušení, by mohlo vést k zamrznutí. Ale jakmile to vypadá, že neběží žádné obsluhy, zapne se zámek popisovače a ještě jednou je zkontrolován stav. Pokud neběží žádné obsluhy, je synchronizace kompletní; jinak se kód vrátí k čekání. Získání zámku popisovače zaručuje, že na obou stranách potenciálního souběhu budou postaveny paměťové bariéry; a to vynutí řazení paměťových operací. S tímto kódem tedy synchronize_irq() provede opravdovou synchronizaci s obsluhami IRQ a nepříjemný souběh bude odstraněn.
O sporném API linuxových bezpečnostních modulů (LSM) už se na LKML zase mluví. Ne o odstranění, proti kterému rázně vystoupil Linus Torvalds, ale jestli by mělo být možné natahovat bezpečnostní moduly dynamicky. V rámci 2.6.24 Linus začlenil patch pro převedení LSM na statické rozhraní, ale dal najevo, že by byl ochoten jej stáhnout. Základní otázkou je, jestli existují bezpečnostní moduly, které vyžadují možnost natažení za běhu.
Na základě stížnosti ohledně této změny od Thomase Fricaccia Linus požádal, aby se přihlásili lidé, kteří u LSM natahování používají. Pokud se někdo najde, mohl by být patch zase odstraněn. Linus opět zapochyboval, jestli jsou vývojáři bezpečnostních systémů duševně zdrávi, ale přesto vyzval, ať se ozvou případní uživatelé:
Rád bych poznamenal, že jsem prosil lidi, kterých se to opravdu týká, ať dají vědět, protože jsem výslovně uvedl, že jde o věc, kterou můžeme snadno vrátit.
Jan Engelhardt reagoval informací o svém modulu MultiAdmin, který umožňuje více rootů na systému - každého se svým vlastním UID. Díky tomu je možné individuální sledování vlastnictví souborů, využívání zdrojů apod. u každého administrátora. MultiAdmin také umožňuje vytváření sub-administrátorů, kteří mohou provádět některé rootovské činnosti u procesů a souborů, které vlastní určitá část uživatelů. Uplatnění se najde třeba u profesorů, kteří mohou spravovat účty svých studentů, aniž by získali plná práva roota.
James Morris, který změnu na statické LSM navrhl, odpověděl, že MultiAdmin pravděpodobně splňuje kritéria reálného využití. Není sice jasné, jestli MultiAdmin potřebuje rozhraní pro natahování, ale každopádně ho používá. Natahování a odstraňování modulu implementuje i root_plug, který povolí start root procesů jen za předpokladu, že je připojeno konkrétní USB zařízení (vizte Autentizace a autorizace USB zařízení). V obou případech by konfiguraci šlo provést prostřednictvím sysfs, kde by byly příznaky pro vypnutí a zapnutí.
U uvedených příkladů znamená možnost moduly natahovat zjednodušení práce administrátorů. Hlavními uživateli jsou však vývojáři. Crispin Cowan to shrnul:
Proč byste chtěli dynamicky odstraňovat modul? Protože je to pohodlné při debuggování. OK, není to bezpečné a občas to zasekne jádro, takže je nutné restartovat. S tímto patchem musíte restartovat pokaždé, když chcete vyzkoušet změnu modulu.
Kompromisním řešením by mohl být patch, který poslal Arjan van de Ven. Ten převádí LSM na statické nebo natahovatelné rozhraní podle volby zadané při konfiguraci jádra. Vypadá to, že panuje shoda, že jde o rozumný přístup, který ponechá rozhodnutí na distribucích a uživatelech. Linus se zatím nevyjádřil a v 2.6.24-rc1 je stále "statický" patch.
Dynamické natahování bezpečnostních modulů je potenciálním zdrojem problémů - je snad lepší místo pro schování rootkitu? Ale existují platné důvody, proč by to někdo mohl chtít používat. Linux se snaží být otevřen mnoha způsobům využití, včetně těch, které mohou vývojářům jádra připadat nechutné. Dynamické natahování bezpečnostních modulů je zjevně jedním z nich.
Každý linuxový proces si nese sadu dokladů [credentials], které popisují jeho práva v systému. Doklady obsahují uživatelské ID, členství ve skupinách, kvalifikace, bezpečnostní kontext a další. Tyto doklady jsou uloženy ve struktuře task_struct přiřazené ke každému procesu; operace, která mění doklady, to dělá přímo ve struktuře task_struct. Tento přístup fungoval mnoho let, ale jeho stáří se už začíná projevovat.
Konkrétně tento současný způsob ztěžuje život jadernému kódu, který potřebuje na určitou dobu převzít jiné doklady. Ve snaze situaci napravit poslal David Howells patch, který práci s doklady procesů výrazně mění. Výsledkem je komplexnější systém, který je však pružnější a snad i bezpečnější.
Základní myšlenkou patche je to, že by všechny doklady procesu (atributy, které popisují, jak smí proces nakládat s dalšími objekty) měly být vytaženy ze struktury procesu do vlastní samostatné struktury. Vznikla tedy struktura struct cred, která obsahuje uživatelské a skupinové ID podle souborového systému, seznam členství ve skupinách, platné kvalifikace, skupin klíčů procesu [keyrings], obecný ukazatel pro bezpečnostní moduly a další informace. Způsobí to docela velké změny kódu, protože každý přístup ke starým informacím o dokladech musí být převeden na novou strukturu cred.
Změny komplikuje skutečnost, že se podstatná část dokladových informací do cred v reálu nepřesenula; jsou tam jen zrcadleny. Jedním ze základních pravidel fungování struct cred je to, že tuto strukturu může měnit pouze proces, který popisuje. Takže všechno, co v té struktuře může být měněno i něčím jiným - například kvalifikace a skupiny klíčů - zůstává v task_struct a do struktury cred je to kopírováno podle potřeby. "Podle potřeby" v praxi znamená kdykoliv mají být doklady zkontrolovány. Takže většinu systémových volání ozdobí tento kousek kódu:
result = update_current_cred();
if (result < 0)
return result;
Další pravidlo říká, že struktura cred nesmí být měněna, jakmile byla přiřazena k úloze. Místo toho se musí použít RCU technika, při které je struktura cred zkopírována, nová kopie je změněna a ukazatel task_struct je pak nastaven na novou strukturu. Ta stará, na kterou odkazují reference, zůstává, dokud je používána, a nakonec se odstraní pomocí RCU.
K dispozici je celá sada funkcí - utilitek pro práci s doklady. Některé z nich:
struct cred *get_current_cred();
void put_cred(struct cred *cred);
Volání get_current_cred() bere referenci na strukturu cred aktuálního procesu a vrací ukazatel na ni. put_cred() referenci uvolňuje.
Změna struktury dokladů většinou zahrnuje volání:
struct cred *dup_cred(const struct cred *cred);
void set_current_cred(struct cred *cred);
Aktuální doklady mohou být zkopírovány pomocí dup_cred(); pozměněný duplikát lze nastavit jako aktuální prostřednictvím set_current_cred(). Byla přidána nová sada háčků [hooks], které umožňují bezpečnostním modulům, aby se na duplikaci a nastavování dokladů podílely.
Prozatím tato infrastruktura vypadá jako hromada práce navíc a žádný viditelný přínos. Směr, kterým se David s touto změnou ubírá, je vidět v této nové funkci:
struct cred *get_kernel_cred(const char *service,
struct task_struct *daemon);
Účelem této funkce je vytvořit novou strukturu dokladů s potřebnými právy pro danou service. Ukazatel daemon označuje aktuální proces, který by měl být použit jako zdroj nových dokladů - nová struktura cred umožní svému držiteli vystupovat, jako by to byl proces daemon. Aktuální bezpečnostní modul dostane příležitost změnit, jak jsou doklady nastaveny; interpretace řetězce "service" vlastně probíhá pouze v bezpečnostních modulech. V případě absence bezpečnostního modulu pouze get_kernel_cred() duplikuje doklady, které drží daemon.
Tato funkčnost je využívána v Davidově patchsetu FS-Cache (dříve cachefs). FS-Cache implementuje lokální keš pro síťové souborové systémy; taková lokálně uložená keš bude samozřejmě vystavena stejným bezpečnostním rizikům jako vzdálený souborový systém. Existuje démon, který odvádí část práce spojené se správou keše, ale další přístupy do keše provádí kód FS-Cache, který běží v kontextu procesu, jež pracuje se soubory na vzdáleném souborovém systému. S pomocí výše uvedené funkce může kód FS-Cache přidělit práva démona kterémukoliv procesu právě na tak dlouho, kolik je k dokončení práce se souborovým systémem potřeba.
Výsledkem je to, že může být bezpečnostní politika zanesena hlouběji do jádra než dříve. V případě FS-Cache pracuje jaderný kód, který provádí kešování, vždy s kvalifikacemi démona pro správu keše. Takže všechny ochrany, SELinuxy atd., které platí pro démona, budou také platit, když se s FS-Cache pracuje v jiném kontextu. Systém by měl být celkově bezpečnější.
Práce na dokladech je pořád v relativním raném stádiu a zbývá toho ještě hodně. Až budou provedeny všechny vyžadované změny v jádře, bude to dost velký patch. Nejedná se tedy o kandidáta pro 2.6.24. Práce však pokračuje, takže na dveře hlavního stromu pravděpodobně zaklepe brzy.
Nástroje: Tisk bez diskuse
Tiskni
Sdílej:
Dneska je to fakt bída.
, a proto nedělám literaturu. 
)
14.11.2007 07:46
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
s/prodrobnosti v douhém/podrobnosti v dlouhém/
14.11.2007 21:19
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
15.11.2007 00:45
Prcek | skóre: 43
| Jindřichův Hradec / Brno
.
V tuto chvíli nevím o žádném běžně používaném hardwaru, který by v Linuxu nebyl nepodporován.Má být: "...by nebyl podporován."
Dobrý nápad, snad se to ujme.
. Mozna kdyby na to byla zvlastni funkce/formular na hlaseni chyb v clancich, tak snad...
14.11.2007 21:21
Marián Kyral | skóre: 29
| blog: Sem_Tam
| Frýdek-Místek
Proměnnou flags používá kód (který je specifický pro jednotlivé architektury) k uložení stavu přerušení, jež by mohl být potřeba, když je volána spin_unlock_irqrestore().-> Proměnnou flags používá kód (který je specifický pro jednotlivé architektury) k uložení stavu přerušení, jenž by mohl být potřeba, když je volána spin_unlock_irqrestore(). Proměnnou flags používá kód (který je specifický pro jednotlivé architektury) k uložení stavu přerušení, jež by mohlo být potřeba, když je volána spin_unlock_irqrestore(). Proměnnou flags používá kód (který je specifický pro jednotlivé architektury) k uložení stavu přerušení, jež by mohla být potřeba, když je volána spin_unlock_irqrestore(). Co z toho jste měl, autore, na mysli?
14.11.2007 22:00
14.11.2007 09:16
