C++ a Linux kernelben

Kernel

A Reykjavik University Network Laboratory egyik kutatója olyan patchet készített, amely lehetővé teszi, hogy teljes, kernelszintű runtime C++ támogatással rendelkezzen a Linux kernel.

Jah, hát nem :) De azért szépen haladnak.

Persze még elég messze van, hogy valóban használható legyen bármire.

Meg van az ára, hogy nincs többé buffer overflow, s a programok nem csinálhatnak egy pointerből long-ot, aztán vissza ... vagy nem tehetnek a stackra mindenféle trükkös értéket.

Valószinüleg mondjuk linuxhoz viszonyitva egy 50%-os sebességet simán el fognak tudni érni.

Ahogyan már mások is megtették (http://www.jxos.org)

Szerintem sokkal izgalmasabb lenne, ha lenne a kernelben ... sőt, ha az egész kernel Prologban lenne írva! :)

Ennél messzebb azt hiszem nem kerülhetünk a lowlevel rendszerprogramozástól.

Bár azért az sem lenne semmi, ha a kernelt teljesen UML-ben "írnák", és aztán valami automatikus kódgeneráló eszköz készítene belőle mondjuk Java forrást, amit aztán még egy-két további lépésben le lehetne fordítani gépi kódra. Már látom is magam előtt: kernel bináris mérete 30MB, memóriafoglalása legalább 100MB, betöltés, inicializálás bootoláskor 15 perc. A generáltatás és fordítás pedig kb 20óra. És mindez persze egy Opteronos gépen.

IBM's Vision r0xXX!

:) :P

Akkor nezzetek meg, mit [www.cs.kun.nl] talalhatnak meg ki, es miert. Az illeto otletet Hilde-nek hivjak es jelenleg meg csak Windows "fele" van elkeszitve, de ha mukodokepes lesz, akkor bizonyara az ellinuxosodast sem fogja elkerulni. Termeszetesen "ez is" egy egyetemi otlet (PhD disszertacio temaja), szoval erdemes elovasni a hozza kapcsoldo publikaciokat. Bar mar a "Research" reszben szereplo tudnivalok is felfedik, itt nem a komplexitas novelese a cel, hanem az egyszeruseg es a hibamentesseg.

Aha, csak én most önlab keretében pont ilyennel foglalkozom, és szerintem nem akarod hallani a véleményemet a generált kód minőségéről...

Nem elég, hogy tele van felesleges sallangokkal, és 5x akkora, mint kéne, de néha vannak benne SZINTAKTIKAI(!) hibák is, amiket kézzel kell utána javítgatni.

Ezek után én nem hiszem, hogy belátható időn belül eljutnánk arra a szintre, amit a marketingszöveg hirdet.

Ja és az UML magában messze nem jelenti azt, hogy valami matematikailag bizonyítható lenne. A kernelnél sokkal egyszerűbb dolgokról is iszonyatosan nehéz bizonyítani még olyan alap állításokat is, hogy pl deadlockmentes.

( trey | 2004. 10. 28., cs – 11:10 )

Linus orulni fog neki, mert koztudottan szereti a C++-t a kernelben :-)

( lgb | 2004. 10. 28., cs – 11:15 )

Pfff ... Shell script nem lehet a kernelben? Perl? Esetleg BASIC? Sose ertettem hogy miert kell mindent eroltetni annyira, amikor ott van a C. Ilyen project-eket azok talalnak ki akik nem ertenek a C-hez. Mas otletem nincs, de komolyan: MIERT jo az valakinek hogy C++ lesz a kernelben? Azon kivul hogy minden lassabb es nagyobb lesz mint volt?

( danesdzsu | 2004. 10. 28., cs – 11:43 )

A sátán megérkezett, a világ megérett a pusztulásra.

:)

De nincs ertelme, pont ez a lenyeg! Ha valaki fejleszt egy kernelt ami gyokereiben C++ akkor legyen. De a Linux kernel egesz idaig C-ben irodott, egyszeruen NINCS ertelme hogy akkor most csak azert noveljuk annak komplexitasat (es igy persze a hibalehetosegek szamat, eroforrasigenyet stb) mert egyesek nem tudnak C-ben kernelt fejleszteni es C++ kene nekik :) Amugy szerintem ezek a project-ek inkabb amolyan egyetemi project-ek: valos ertelme nem sok, de lehet belole tanulni. Arra mondjuk jo ...

Reszlet egy korabbi interjubol:

``Alessandro: Many people ask why the kernel is written in C instead of C++. What is your point against using C++ in the kernel? What is the language you like best, excluding C?

Linus: C++ would have allowed us to use certain compiler features that I would have liked, and it was in fact used for a very short timeperiod just before releasing Linux-1.0. It turned out to not be very useful, and I don't think we'll ever end up trying that again, for a few reasons.

One reason is that C++ simply is a lot more complicated, and the compiler often does things behind the back of the programmer that aren't at all obvious when looking at the code locally. Yes, you can avoid features like virtual classes and avoid these things, but the point is that C++ simply allows a lot that C doesn't allow, and that can make finding the problems later harder.

Another reason was related to the above, namely compiler speed and stability. Because C++ is a more complex language, it also has a propensity for a lot more compiler bugs and compiles are usually slower. This can be considered a compiler implementation issue, but the basic complexity of C++ certainly is something that can be objectively considered to be harmful for kernel development.''

handler> Bytecode interpreter mar van benne, sot scheme interpreterrol
handler> is tudok patch formajaban ;-)

Wow, common lisp patch nincs esetleg valahol? =)

Hmm ilyen kernelbe epitett Emacs az milyen lehetne? Alt-sysrq kombora
beficcenne izombol, hogy mire lenne ez jo azt meg nemtom:)

--
....sutongi tti olleh

( nevergone v | 2004. 10. 28., cs – 13:36 )

Lassan jön a 100 % -ig Java kernel... :)