Linus Torvalds: Linux 2.6.25-rc8

Kernel

Linus tegnap kiadta a 2.6.25-ös Linux kernel nyolcadik kiadásra jelölt verzióját. Mint írta, semmi április elsejei trükk sincs benne, csak a szokásos -rc kiadás. A változtatások nagy részét szokás szerint véletlenszerű egysorosok teszik ki. Ezek többsége elszórt kódtisztítás. Ami valószínűleg a legtöbb ember számára látható vagy "érezhető" lesz: két top prioritású regresszió került javításra ebben az -rc kiadásban. Részletek a KernelTrap cikkében. A bejelentés itt olvasható.

( pinyo_villany | 2008. 04. 02., sze – 18:31 )

2.6.25-rc7-git2 


Listed regressions statistics:
 
  Date          Total  Pending  Unresolved
  ----------------------------------------
  2008-03-27      171       38          30
  2008-03-22      159       35          31
  2008-03-17      148       38          30
  2008-03-16      146       42          35
  2008-03-14      145       45          39
  2008-03-12      143       51          41
  2008-03-11      141       58          43
  2008-03-10      138       66          47
  2008-03-03      115       65          49
  2008-02-25       90       51          39
  2008-02-17       61       45          37

nézz a számok mögé, és lásd meg az összefüggést :)

debian gnu/linux @ linux-2.6.22.20-op1 | patch
info

Nem olvastam utána, de érzésre ezek a regressziók ad-hoc funkcionális teszteken (lefordul-e Gézánál a kernel, bebootol-e Jocó gépén, megy-e a suspend Macaulay Fujitsuján, stb), nem pedig a forráskód nagy részét egzecíroztató unit tesztek során buknak ki.

Azaz egy bohócparádé az egész. :) (komolyabban fogalmazva: a nem létező bugtracking rendszer hevenyészett havi riportja az ismert, nyitott, stb hibákról)

jó kérdés ... szerintem aki vanilla kernelt használ, az is pancsolja saját magának valamennyire és a saját gépéhez igazítja ahol kell, mert van jópár dolog, ami nincs benne, de szükség lenne rá (most magamból indultam ki)

debian gnu/linux @ linux-2.6.22.20-op1 | patch
info

A unit teszt csodalatos dolog, azonban itt nem Java vagy C# nyelven, objektum orientalt paradigma menten irodott, lazan csatolt kodrol van szo, hanem erosen allapotos, konkurrens es kulso hardverekre (is) epito C kodrol.

Kb. a kovetkezok a nehezsegek:

- A C nyelvi kod unit tesztelese nehezebb, mint az OO nyelvek eseten. Hiszen OO eseten adodik, hogy a teszt alapja az osztaly, melybol egy peldanyt letrehozva, adott allapotra beallitva lehetseges a teszteles. C eseten nincs ilyen termeszetes hatar, hanem azt valahogy onkenyesen kell kijelolni, allapottal feltolteni, stb. Egy OS kodja ebbol a szempontbol rosszabb is, mint egy altalanos uzleti alkalmazas, mivel a hatekonysag illetve konkurrencia szempontok miatt nagyon sok globalis allapotvaltozo van. Erdemes vegiggondolni, hogy mondjuk egy swapolast szabalyozo kod tesztelesehez kb. mi mindennek kell a helyen lennie, mire a tesztelendo kodreszletet futtatni lehetseges.

- Hogyan tesztelheto az olyan kod, ami feltetelezi, hogy teljes jogosultsaggal fut a gepen (ring 0)? Egy-egy fuggvenyen sokat kellene makrozni, mire sikerul annyira "megszeliditeni" hogy egyszeruen egy felhasznaloi process reszekent futtathato (=tesztelheto) legyen.

- Hogyan tesztelheto egy driver? Le kellene szoftverben szimulalni a hardvert, ami termeszetesen nem lehetetlen, de sok munka. Lehetne igazi hardvert is hasznalni a teszteleshez, azonban ez nehezen automatizalhato, lassu es draga.

- Hogyan tesztelheto a konkurrencia helyes kezelese? Ez sem megoldhatatlan, de trukkos es munkas.

A unit teszteles a fenti okok miatt nehezkes, automatizalt, felhasznaloi oldalrol kozelito tesztek pedig mar most is vannak (tobbek kozott) a Linux Test Projekt kereteben.

"- Hogyan tesztelheto az olyan kod, ami feltetelezi, hogy teljes jogosultsaggal fut a gepen (ring 0)? Egy-egy fuggvenyen sokat kellene makrozni, mire sikerul annyira "megszeliditeni" hogy egyszeruen egy felhasznaloi process reszekent futtathato (=tesztelheto) legyen.
"

UML (user mode linux),qemu,kvm.. nemileg segithet.