A 2.6.31-es kernelbe egyebek mellett
- USB 3.0 támogatás
- CUSE (a FUSE megfelelője karakter eszközökre)
- néhány, a desktop interaktivitást javító memóriakezelési változtatás
- fejlettebb readahead
- ATI Radeon modesetting támogatás
- Intel Wireless Multicomm 3200 WiFi támogatás
- teljesítményszámlálók kernel oldali támogatása (és hozzá egy userspace eszköz)
- gcov támogatás
- memchecker az inicializálatlan memória ellenőrzésére
- memóriaszivárgás detektor
- az inotify és a dnotify reimplementációja
- btrfs fejlesztések
- az IEEE 802.15.4 hálózati szabvány támogatása
- IPv4 over Firewire
- stb.
érkezik.
A teljes lista megtekinthető itt.
- A hozzászóláshoz be kell jelentkezni
- 3473 megtekintés
Hozzászólások
2.6.31-rc5 öst használom nagy megelégedéssel főleg az intel GMA lett stabil. :>
Core2Duo T7100, 4G, Ubuntu 9.04, 2.6.31-rc5
- A hozzászóláshoz be kell jelentkezni
2.6.30-ban se tapasztalok vele problemat :)
- A hozzászóláshoz be kell jelentkezni
ez a CUSE betette a bogarat a fülembe, tetszik a gondolat, hogy minél több dolog legyen userspace-ben. Az a benyomásom, hogy ezzel csökkenthető annak a veszélye, hogy a teljes kernelt magával rántsa egy driver …vagy?
—-—-—
int getRandomNumber() {
return 4;//szabályos kockadobással választva.
} //garantáltan véletlenszerű. xkcd- A hozzászóláshoz be kell jelentkezni
Viszont performancia rosszabb, nyilvan, hiszen context switch-ek, stb. Amugy meg ha ez a cel, akkor mikrokernelekkel kell foglalkozni. Mondjuk ami Linux eseten van FUSE, stb az szerintem jo, mint kb kozeput, mert mondjuk az sshfs-t en nagyon csipem, de eszembe nem jutna azert, hogy valaki kernel space-ben implemental sshfs-t :) Szoval vannak teruletek, ahol ez nagyon is jo dontes, viszont altalanossagban, ha minden user space driverekbe akarunk nyomni az mar mikorkernel lenne, es nem monolitikus, onnantol ...
- A hozzászóláshoz be kell jelentkezni
jó-jó, de miért baj, ha nem monolitikus? Sőt, miért baj, ha esetleg választhatsz is, hogy valamit beleraksz-e a monolitba, vagy hagyod, hogy külön legyen?
—-—-—
int getRandomNumber() {
return 4;//szabályos kockadobással választva.
} //garantáltan véletlenszerű. xkcd- A hozzászóláshoz be kell jelentkezni
A monolitikus - mikrokerneles szetvalasztas es szembeallitast nem tartom alkalmasnak a parbeszedre. Az oprendszer tudomanya ennel bonyolultabb, a fejlodes nem egyiranyu.
Monolitikusnak szoktak hivni a linuxot, foleg Tannenbaum prof kifakadasa miatt. Pedig a klasszikus monolitikusnak hivott kernelekben nincs modul, plane nincs modul unload, foleg nincs 3rd party modul, a linux kernelben mindez van/lehet. Mostansag olyan ertelemben hasznaljak a monolitikus ellentettjet, hogy a kernel kulonbozo reszletei egymastol elszeparalt vedelmiszinteken futnak (a lapozo/utemezo ring0, a tobbi ring3 (userspace) vagy ring1). Ez a NT (new technology) elve, ezt lathatod a windows NT -ben (3.51-ig, mert utana ok is visszatertek az egesz kernelfunkciaonalitas a ring0 -ban elvhez). 1970-1980 tajekan gondoltak ugy, hogy ezzel (a szeparacioval) novelheto a rendszer stabilitasa. Hiszen, ha a kernel - userland szetvalasztas hasznos (lattuk) akkor a kernelen beluli szeparacio is hasznos lesz. Ez nem valt be. Nem csak teljesitmenyokok miatt, hanem elvi ok miattsem: ha egy modulra nincs szukseg a kernelben, akkor nem adodik ra a vezerles, hibara sem fut. Ha meg szukseg van egy modulra, akkor szinte mindegy, hogy ring3, ring1 vagy ring0 -ban hasal meg, a top level szolgaltatas igy is, ugy is megall. Kernelfejlesztesnel hasznos, de ugy nez ki, hogy kernelfejlesztsenel a fejlesztok szamanak nyers tomege mervadobb.
Szoval, mindezek miatt ugy erzem, hogy a monolitikus, mikrokerneles kategoriak majdnem hasznalhatatlanok, marmint olyan beszelgeteseken tul, hogy a juventus a jobb csapat, vagy a real madrid.
- A hozzászóláshoz be kell jelentkezni
köszönöm.
—-—-—
int getRandomNumber() {
return 4;//szabályos kockadobással választva.
} //garantáltan véletlenszerű. xkcd- A hozzászóláshoz be kell jelentkezni
A CUSE pont egy olyan alrendszer aminek sebesség szempontjából mindegy hogy user vagy kernelspace-ben fut, jó ötlet kiszedni onnan.
- A hozzászóláshoz be kell jelentkezni
vagy.
a userspace programozok tobben vannak, mint a kernelspace programozok. Ha minel tobb fele filesystem/character driver tobbe/kevesbe implementalasa a cel, akkor nem art, ha van (egy barmilyen sebessegu) userspace hook lehetoseg. A legelterjedtebb driverek bele fognak kerulni a kernelbe, mar csak a sebesseg miatt; azonban varhatoan sokkal tobb userpsace baromkodas lesz mindig. Nem art, ha van ilyen funkcioja is egy kernelnek. Is.
A linux fejlodeset hatterbol nezve nem tartom valoszinunek, hogy egy funkcio azert kerulne bele, hogy attol stabilabb legyen a kernel :-)
- A hozzászóláshoz be kell jelentkezni
Hihetetlen mennyi újítás van ebben a kernelben, de a korábbi kiadások sem maradnak el sokkal.
- A hozzászóláshoz be kell jelentkezni