Linux

NE vegyünk SONY cd-rw eszközöket, árthat kernelünk egészségének!

Egy az LKML-re (Linux Kernel Mailing List) postázott levél szerint a Linux kernel panic-olhat (2.4.19, 2.4.20-pre11), ha másolásvédett CD-ket próbálunk olvasni. Ennek az oka az, hogy vannak bizonyos eszközök, amelyek mindenáron meg próbálják akadályozni azt, hogy másolásvédett CD-ket olvassunk.Andre Hendrick - az IDE kód karbantartója - állítja, hogy ez normális körülmények között nem következhet be. Ezen kívül még megjegyzi, hogy ha tehetjük ne vásároljunk SONY cd-rw termékeket.

Kerneltrap cikk itt.

Az LKML thread itt kezdődik.

Elkészült a cdw - konzolos CD író front-end - 0.1.4-es verziója. Az újdonságok között szerepel, hogy már van lehetőség CD katalógus kezelésére is. Kérésre írás után automatikusan hozzáadja a frissen égetett CD-t a katalógushoz.Ez a feature csak akkor működik, ha a dic telepítve van. A kódba került továbbá néhány hibajavítás is. A források és a deb csomag letölthető a project honlapjáról:
http://cdw.sourceforge.net



Minden hozzásszólást, megjegyzést, javaslatot vagy kritikát várok az alábbi címen:
vbali@westel900.net

Megjelent Andrew Morton legújabb foltja a 2.5.44-es kernelhez. Aki letöltötte a fent említett kernelforrást (2.5.44), és megpróbálta lefordítani az számos fordítási hibával találhatta szemben magát. Sajnos nem minden esetben fordul le a 2.5.44-es kernel.

Andrew foltja számos hibát javít. Töltsd, tesztelj, bugreportolj, járulj hozzá te is a kernel fejlesztéséhez!

A patch letölthető 2.5.44-mm2.gz

Változások logja Andrew levelében itt.

Rob Landley a Linux and Main egyik szerkesztője egy levelet küldött az LKML-re, melyben felvázolta a Linux fejlesztői kernel további sorsát.

Levelében bejelentette, hogy Linus eltávozott a Linux Lunacy II rendezvényre, amely a Karib tengeren kerül megrendezésre, és ott is marad egészen október 27-ig. Amikor visszatér még lesz egy lehetőség arra, hogy az összegyűlt patchek bekerülhessenek a következő kernel sorozatba (2.6-pre vagy 3.0-pre ebben még nem egyeztek meg, de valószínű, hogy 3.0 - trey).Amíg Linus a Karib tengeren hajókázva "előad", addig az itthon maradt kernefejlesztőknek jó volna tudni, hogy mik azok az új funkciók amelyet bele szeretnének még tenni a következő sorozatba az emberek. Tehát nem a bugfixekről van szó, hanem csak az új dolgokról.

Az október 19-én megjelent Linux kernel státusz riport - amelyet Guillaume Boissiere készített - a következő bejegyzéseket tartalmazza a "beolvasztásra kész" részben:

# PCMCIA Zoom video support (Alan Cox) http://www.uwsg.iu.edu/hypermail/linux/kernel/0203.1/0326.html

# Device mapper for Logical Volume Manager (LVM2) (LVM2 team) http://www.sistina.com/products_lvm.htm

# VM large page support (Many people) http://lse.sourceforge.net/

# Page table sharing (Daniel Phillips, Dave McCracken) http://www.geocrawler.com/mail/msg.php3?msg_id=7855063&list=35 (or possibly here:) http://lists.insecure.org/lists/linux-kernel/2002/Oct/6446.html

# Ready - Build option for Linux Trace Toolkit (LTT) (Karim Yaghmour) http://www.uwsg.iu.edu/hypermail/linux/kernel/0204.1/0832.html

# Ready - Dynamic Probes (dprobes team) http://oss.software.ibm.com/developerworks/opensource/linux/projects/dprobes

# Ready - Zerocopy NFS (Hirokazu Takahashi) http://www.uwsg.iu.edu/hypermail/linux/kernel/0204.1/0429.html

# Ready - High resolution timers (George Anzinger, etc.) http://high-res-timers.sourceforge.net/

# Ready - EVMS (Enterprise Volume Management System) (EVMS team) http://sourceforge.net/projects/evms

# Ready - Linux Kernel Crash Dumps (Matt Robinson, LKCD team) http://lkcd.sourceforge.net/

# Ready - Rewrite of the console layer (James Simmons) http://linuxconsole.sourceforge.net/

Ehhez még hozzás lehet adni az újabb levelezések alapján az alábbit:

# Ready- Kexec, luanch ELF format linux kernel from Linux (Eric W. Biederman) http://lists.insecure.org/lists/linux-kernel/2002/Oct/6584.html

Ezek után Rob a következőket írta:

"Ha a patched nincs fenn a listán, és a linux-kernel listán levő emberek nem tesztelik jelenleg, akkor most szólj, hogy felkerüljön a listára, vagy várj a következő fejlesztői kernelig."

Megkér mindenkit, hogy a fenti patcheket tesztelje aki tudja, és ha működik akkor jelezze a kernel listára.

"Szólj most, vagy maradj csendben a 3.1-ig..."

Robert levele itt.

Kapcsolódó hírek:

Linus Torvalds: Linux v2.5.44 - és offline egy hétig

Halloween: Linux új funkciók fagyasztása (feature freeze)

"Ok. Beolvasztottam több ember anyagát, és a 2.5.44 kinn van. Egyre közelebb vagyunk, srácok." (feature freeze - trey)

"A következő 8 napban (ami _most_ kezdődik) teljesen felesleges patchet küldeni, vagy cc-zni nekem... Nem fogom elolvasni, és amikor visszatérek, akkor üríteni fogom az egész inbox-om..."

"Ismétlem: amíg nem leszek itt, kérlek használjátok a linux-kernel-t, mint a beszélgetések központját.... Ne töltsd tele a mailboxom..."

Szóval Linus elment, a 2.5.44 meg kijött.

Letölthető patch-2.5.44.gz, FULL

Változások itt.

Linus levele:From: Linus Torvalds

To: Kernel Mailing List

Subject: Linux v2.5.44 - and offline for a week

Date: 18 Oct 2002 21:24:38 -0700

Ok, I've merged stuff from more people, and 2.5.44 is out there. We're getting closer, folks.

And for the ext 8 days (starting _now_) it is totally unnecessary to try to send me patches or cc me on the discussions about what needs to be merged or not. I won't read it, and when I get back I will likely just flush the whole inbox, since there's no way I can try to catch up _and_

try to merge some final pieces before the feature freeze at the same time.

I've asked various people to act as merge-points for me while I'm gone, and to avoid having them mailbombed or pressured into accepting stuff they don't really want to, I won't even tell who they are ;)

Anyway, the 2.5.44 patches are all over the map, see for yourself in the appended changelog.

I repeat: while I'm gone, please use linux-kernel as a central point for discussion, and I assume that all the normal suspects will maintain their own set of fixes for it. Don't fill my inbox,

Linus

[...]

Nézegetem az LKML leveleket, és észreveszek egy levelet aminek a subjectje "Linux Security Protection System". Na nézzük csak mi ez. Bosko Radivojevic küldte a levelet, amelyben bejelenti az első publikus stabil verzióját a LinSec-nek. A LinSec a "Mandatory Access Control (MAC)" mechanizmust valósítja meg a Linux rendszerekben. A LinSec két részből áll, egy kernel patchből, és "user space" eszközökből. Az első publikus verzió a 2.4.18-as kernelhez készült.

Részletes dokumentáció, letöltés, levelező lista a project honalpján:

http://www.linsec.org

Bosko levele:From: Bosko Radivojevic

To: linux-kernel@vger.kernel.org

Subject: Linux Security Protection System

Date: 16 Oct 2002 16:08:54 +0200

LinSec team is proud to announce first stable release of LinSec.

LinSec, as the name says, is Linux Security Protection System. The main aim of LinSec is to introduce Mandatory Access Control (MAC) mechanism into Linux (as opposed to existing Discretionary Access Control mechanism).

LinSec model is based on:

* Capabilities

* Filesystem Access Domains

* IP Labeling Lists

* Socket Access Control

As for Capabilities, LinSec heavily extends the Linux native capability model to allow fine grained delegation of individual capabilities to both users and programs on the system. No more allmighty root!

Filesystem Access Domain subsystem allows restriction of accessible filesystem parts for both individual users and programs. Now you can restrict user activities to only its home, mailbox etc. Filesystem Access Domains works on device, dir and individual file granularity.

IP Labeling lists enable restriction on allowed network connections on per program basis. From now on, you may configure your policy so that no one except your favorite MTA can connect to remote port 25

Socket Access Control model enables fine grained socket access control by associating, with each socket, a set of capabilities required for a local process to connect to the socket.

LinSec consists of two parts: kernel patch (currently for 2.4.18) and userspace tools.

Detailed documentation, download & mailing list information -

http://www.linsec.org

"Nagy patch küldési láz vette kezdetét a feature freeze miatt..., a nagyobb változás az RCU és az oprofile, de változások vannak az egész kernelben..." - írta Linus az LKML-re.

Letölthető patch-2.5.43.gz, FULL

Változások logja itt.

"Itt a pre11, néhány különböző javítással." - írta Tosatti.

Letölthető patch-2.4.20-pre11.gz.

Változások logja itt.

Dominik Brodowski nekiállt írni egy új CPU frekvencia szabályzó alrendszert, amelyet Linus beintegrált a 2.5.40-es verziójú Linux kernelbe. Ez a kód lehetővé teszi, hogy a CPU(k) frekvenciáját "user-space", azaz felhasználói szinten állítani tudjuk. Természetesen csak azoknál a processzoroknál lehetséges ez, amelyek támogatják ezt a funkciót.

Valaki csodálkozhat azon, hogy miért jó az, ha egy CPU-t a névleges frekvenciája alatt akarunk hajtani. Ennek mi értelme? Tehetné fel bárki a kérdést. Hiszen így lassabb lesz a gép. Az ok az lehet, hogy csökkentsük a processzor által felemésztett energia mennyiségét, azaz takarékoskodjunk az energiával. A másik ok a hőmérséklet szabályozás lehet. A gyorsabb CPU több energiát fogyaszthat. Ha például a notebookodat használod egy repülőgépen, akkor nem biztos, hogy az a célod, hogy titkosított kulcsokat törjél fel, vagy éppen megdöntsd a kernelfordítás világrekordját. Viszont lehet, hogy azt akarod, hogy a processzor lassuljon le egy kicsit, hiszen a sebesség ilyenkor nem a legfontosabb tényező, viszont sokat számít ha a notebook tovább bírja energiával. A másik dolog pedig akkor jöhet szóba, ha a processzor érzékeli, hogy túlmelegedett, és ezért veszi vissza a sebességet, a saját védelme érdekében.Jelenleg több modern processzor is támogatja ezt a frekvencia szabályozási funkciót. Ha a processzor érzékeli, hogy egy ideje üresben jár (idle), akkor elvárható tőle, hogy lassuljon le. Viszont ha az szükséges, akkor önmagától tudjon "felpörögni" újra.

Szóval nem lenne baj, ha lehetne a CPU sebességét valamilyen módon változtani, vagy ezt a dolgot rá lehetne bízni valahogy az operációs rendszerre. A CPU frekvencia kód a 2.5.40 kernelbe lett beolvasztva. Ez lehetővé teszi a felhasználóknak, hogy egy skálán mozogva állítani tudják a CPU frekvenciáját és megfelelő CPU használati policy-t ki tudjanak választani. Ha a felhasználó a "teljesítmény" policy-t választja, akkor a processzor értesítést kap arról, hogy a teljesítményének a felső sávjában kell futnia, és ha le akar lassulni, akkor azt lehetőleg fokozatosan tegye. Ha a felhasználó az "energiatakarékos" üzemmódot választja, akkor a sebességet tartsa lehetőleg alacsonyan, és inkább az akkumulátor energiájával takarékoskodjon. Összegezve, az új felület, egy irányitó, szabályozó eszközt ad a felhasználó kezébe, amellyel be tud avatkozni a rendszere működésébe. Természetesen ez a felület el van kódolva a /proc filerendszerben, amit egy "mezei" felhasználó nem biztos, hogy tud vagy akar "echo" parancsokkal állítgati. Ezért erősen valószínű, hogyel fognak terjedni a KDE és a GNOME alkalmazások, appletek, amelyekel ezt a funkciót tudjuk majd irányítani.

Jelenleg a beolvasztott kód csak az i386 architektúrát támogatja. A kód elérhető lesz több más processzorhoz is a jövőben.

Hogy is működik ez? Valahogy így:

root@notebook:#echo -n "0:0:0:powersave" > /proc/cpufreq

root@notebook:#echo -n "1%100%100%performance" > /proc/cpufreq

root@notebook:#echo -n "1000000:2000000:performance" > /proc/cpufreq

Bővebb infóért nézd meg a Documentation/cpufreq -t a 2.5.40 kernelforrásban.

Tegnap megjelent a 2.5.42. Nem sikerült valami jól, számos fordítási hibát tartalmazott. Mondtam akkor, hogy majd Alan mester rendbeteszi. Valahogy így is lett. Itt az első -ac patch a 2.5.42-höz.

Alan mondja:

"Erősen ajánlom, hogy mondj "N"-t az IDE TCQ opcióra, amúgy le kell fordulnia és futnia kell."

Nem is tudom mi lenne a Linux fejlesztéssel Cox apó nélkül. Szóval a Tagged Command Queue opciót kihagyni, és mehet a tesztelés.

Letölthető patch-2.5.42-ac1.gz

Változások:Linux 2.5.42-ac1

Merge with Linus 2.5.42

o Merge the LVM2 device mapper (Joe Thornber)

o Drop uid16 S/390 bits pending resolution (me)

o Fix iphase build (Adrian Bunk)

o Fix UML build (Kai Germaschewski)

o Fix cpufreq compile (Adrian Bunk)

o Move dead verify_area code from sh port (Brian Gerst)

o Fix missing AIO symbols (Ben LaHaise)

o Fix ATM makefile (Sam Ravnborg)

o Fix esp build (Andres Salmon)

o Fix cifs/jfs symbol name collision (Steve F)

o Update CPIA to match 2.4 tree (Duncan Haldane)

o Fix cifs 64bit and cifs scsi name collision (Steve F)

o Fix a compile of missing sysrq updates (James Simmons)

o Fix sparc timer build (Pete Zaitcev)

o Fix comile without networking (Miles Bader)

o Remove some left over _ret functions (SL Baur)

o Update syncppp code (Paul Fulghum)

o Fix n_hdlc leak (Paul Fulghum)

o Make synclink_cs build again (Paul Fulghum)

o Make synclinkmp build again (Paul Fulghum)

o Make synclink build again (Paul Fulghum)

o Fix NFS symbols for NFS as a module (Olaf Dietsche)

o Fix problem with scsidriver docbook (Joaquim Fellmann)

o Kill dead suspend code in IDE (Pavel Machek)

o Kill unreferenced workqueue define (Pavel Machek)

o Fix swsuspend with discontiguous memory bits (Pavel Machek)

o Fix cpqfc ioctl sense buffer handling (Francis Wiran)

o Sym53c416 from cli to real locking (Bjoern Zeeb)

o Fix a case where sd uses freed memory (Patrick Mansfield)

o Fix p4-clockmod on HT processors (Dominic Brodowski)

o CPUfreq interface update (Dominic Brodowski)

o Fix eicon build (me)

o Restore disconnect field in devices for (me)

driver use