GNU/Hurd: System V Shared Memory implementálva

Hurd

Néhány héttel azután, hogy Neal Walfield implementálta a POSIX szemaforokat a libpthread-hez Markus Brinkmann elkészült a Hurd-os SysV shared memory implementációval a glibc-ben.

( Beanie | 2005. 07. 13., sze – 18:02 )

Hm, végre hallani valamit a Hurd-ről is. Tényleg, használja vki egyáltalán?

Biztos? Ha meg nincs a helyzet magaslatan akkor egyszerubb cross compiling estet jatszani, maga a forraskod buheralasa stb is egyszerubb olyan rendszer alatt ami mukodik is stabilan, kulonben erdekes lenne ha pont azt a bugot kene kijavitani ami a developer gepen a legujabb fejleszteset gyalulta le ... :) Nade komolyan: erdekes lenne tudni mi az igazsag.

LGB wrote:
> Biztos? Ha meg nincs a helyzet magaslatan akkor egyszerubb cross compiling
> estet jatszani, maga a forraskod buheralasa stb is egyszerubb olyan
> rendszer alatt ami mukodik is stabilan, kulonben erdekes lenne ha pont azt
> a bugot kene kijavitani ami a developer gepen a legujabb fejleszteset
> gyalulta le ... :) Nade komolyan: erdekes lenne tudni mi az igazsag.
Én is így gondolom egyébként. :)

( lgb | 2005. 07. 14., cs – 11:14 )

Igazabol nekem erthetetlen az egesz. A Hurd oldalan most is az van hogy Mach mikrokernel igy meg ugy ruleZ, meg a "bolygo legjobbja" vagy hasonlo vetites, aztan kozben mostmar az L4 fole valo atportolasrol van szo. Egyszeruen nem ertem ezek milyen elv szerint csinaljak, mert az egesz olyan mintha random fejlesztenek mindenfele konkret cel nelkul eppen abba az iranyba, amibe eszukbe jut.

A masik meg az, hogy egy mikorkerneles felepitesnek pont az lenne a lenyege hogy a mikrokernelnek koze nincs ahhoz hogy diszk hw szintu kezelese meg ilyesmi, normal esetben az egy elegge primitiv kernel, es servereknek hivott - vegulis processek - formajaban van implementalva mindenfele driver stb, amelyek egymassal is kommunikalhatnak azert persze.

Szerintem jobban jarnanak lassan ha fognak a Linux kernelt (ugyis GPL ;-), kiherelnenek belole minden fs drivert es hasonlot, aztan ala portoljak a hurd servereket ;-) [na jo ez azert nem ennyire egyszeru termeszetesen, felig poen volt, de lehet hogy meg mindig gyorsabb lenne a fejlesztes ...]

On 2005-07-14, LGB <spam@lgb.hu> wrote:
>
> Igazabol nekem erthetetlen az egesz. A Hurd oldalan most is az van hogy
> Mach mikrokernel igy meg ugy ruleZ, meg a "bolygo legjobbja" vagy hasonlo
> vetites, aztan kozben mostmar az L4 fole valo atportolasrol van szo.

Valoszinuleg a honlap kicsit out of date. Nem hinnem, hogy barki is azt
hinne ezen a bolygon hogy Mach rulez... incl. Mach developers.

> A masik meg az, hogy egy mikorkerneles felepitesnek pont az lenne a lenyege
> hogy a mikrokernelnek koze nincs ahhoz hogy diszk hw szintu kezelese meg
> ilyesmi, normal esetben az egy elegge primitiv kernel, es servereknek
> hivott - vegulis processek - formajaban van implementalva mindenfele driver
> stb, amelyek egymassal is kommunikalhatnak azert persze.

In theory, practice is the same as theory... az ido folyaman kisse
ragyogyultak a Machre a sracok, aztan most probalnak leszallni rola. Van
ez igy.

> Szerintem jobban jarnanak lassan ha fognak a Linux kernelt (ugyis GPL ;-),
> kiherelnenek belole minden fs drivert es hasonlot, aztan ala portoljak a
> hurd servereket ;-) [na jo ez azert nem ennyire egyszeru termeszetesen,
> felig poen volt, de lehet hogy meg mindig gyorsabb lenne a fejlesztes ...]

Na most azt mondd meg miafasz erdekes marad a Linux kernelbol, ha
kiszeded belole a drivereket. Meg hogy ez mennyivel lenne jobb, mint az
L4 (amibol ki se kell szedni a drivereket, es raadasul pont affele
funkciok ellatasara irtak, mint ami a Hurdnek kell).

Cs.

Talán azért sem csinálják, mert már van ilyen, az L4Linux. Van egy "hivatalos" L4 linux [l4ka.org], és egy Drezdai egyetem által fejlesztett változat. [os.inf.tu-dresden.de] Ráadásul Ennek egy változatára készítettek egy olyan működőképes rendszert is, ami ki is használja a mikrokerneles mivoltát, pl. 25fps-t megkövetelő real time videoalkalmazásnál. Ez a Drops. [os.inf.tu-dresden.de]


Imho azért nem igen terjedneka 80-as években még oly felkapott mikrokerneles rendszerek, mert hagyományos társaikkal ugyanazt el lehet érni, igaz kicsit több iparosmunkával. Ráadásul az átírt kernelek, mint az apple Darwinja -freebsd on mach- rendre jó 10%-al lassabbak a legtöbb alkalmazásnál mint hagyományos társaik. A MacosX ezek mellé még ki sem tudja használni a Darwin mikrokerneles képességeit. Ugyanez volt az mklinux-al, [www.mklinux.org] ami egy mach alapú linux volt PowerPC-re még a Darwin előtt, és "érdekes" módon az apple szponzorálta.

Ha lesz valaha ütőképes mikrokerneles linux rendszer az L4linux lesz. A hurd meg folytatja a saját útját, részben elvi okokból is. Stallman szerint most nem a Hurd áll az FSF figyelmének a középpontjába, mert a Linux révén úgyis van ütőképes Free kernel.

Bevallom ferfiasan en nem is tudtam, hogy a Tru64 a mach-ra epult.

Azert nekem kicsit ambivalensek az erzeseim ezekkel a mikrokernelekkel. Az tuti, hogy fejleszteni konnyebb oket, de a teljesitmenyukkel lehetnek problemak. A Hurd eleg gyenge probalkozas, a Tru64 nemsoka kihal, legalabbis a HP gozerovel tereli a usereit a HP-UX-ra, az OS X elvan, majd meglatjuk, hogy mit mutat Intel vasakon a tobbiekhez kepest.

Mondjuk a Tru64 tudtommal nem volt kiemelkedo teljesitmenyu kereskedelmi Unix, bar ketsegtelenul olyan szolgaltatasai voltak, amivel megelozte a korat.

Azert irtam a vegen hogy felig poen volt ;-) Azert csak felig mert arra ohajtottam celozni hogy a hurd fejlesztesi sebesseget meg akkor is nehez lenne alulmulni, ha egy nem mikrokernelt kene "mikrokernelesiteni" elobb hozza :) Az L4-et viszont csak par doksi olvasasa szinten ismerem szal arrol velemenyt mondani meg nem akarok.

Nem, az mas ;-) Az a Linux kernel az L4-re portolva. Amit en irtam az az hogy mikrokernelesitsek a Linux kernel legelemibb reszeit csak es a hurd szervereket futassak a folott. De mint irtam ezt inkabb ironianak szantam termeszetesen, azert a Linux kernel nem eppen mikorkernel felepitesu, vagy maskepp: lasd minixLinux vitat anno ...

Az L4Linux viszont I guess sokra nem jo mert nem sok ertelme van egy vegulis onmagaban is mukodo OS kernelt (Linux) portolni egy mikorkernel "ala", max arra hogy igy a Linux kernel mellett mas is futhat L4 alatt, de akkor majdnem csak annyira hasznalja ki az ember mintha egy Xen-rol beszelnek pl, pedig azert az megint mas kategoria.

Eleve a baj ott is hogy sokaktol hallom hogy a "hurd lett volna eredetileg a GNU project kernele", pedig ez pontosan igy nem igaz, mert a hurd egy server gyujtemeny, ami pl Mach mikrokernel folott futnak es egyutesen implementalnak egy UNIX szeru API-t (is).

Azert eljohet meg a valtozas ideje ... Ugyanis a mikrokenel felepites alapvetoen lasabb ,ezen nem erdemes csodalkozni: egy monolitikus OS kernelben ott vannak "egy darabban" a cuccok idoveszteseg nelkul el lehet erni barmit. De itt arrol van szo hogy egymassal kommunikalo kulonallo processek vannak ha szabad igy nevezem hirtelen a dolgot. Viszont ahogy haladunk a szeeeeeep uj jovo fele, egyre nagyobb problema a security (es egyre kenyesebb lesz) az egyre gyorsulo hw-ek miatt a sw fejlesztok pedig regen mar nem a leggyorsabb stb megoldast preferaljak [mas kerdes hogy ez jo-e] mert mas szempontok (lasd: RAD) egyre dominansabba valnak. A nagyobb rendelkezesre allas is lenyeges.

Nos, a mikorkernelek lassabbak, viszont jobban szeparalhato/ellenorizheto a kernelen beluli kooperacio, azaz biztonsagosabb lehet elvileg (nincs olyan hogy egy pointer rossz helyre mutat aztan atirsz veletlenul egy asmik memoriateruletet pl: mert igy max az egyik szerver szalhat el pl es nem az egesz monolitikus os kernel), az egyes szerverek online cserelhetoek, ujak indithatoak stb stb.

Vagy nezzuk a halozatosdit: mivel a serverek egymassal valahogy kommunikalnak, innen egy lepes hogy ezt nem csak gepen belul hanem gepek kozott is megtehetnek: igy egy OS vegulis tobb gepet "olel fel".

En inkabb ugy erzem csak hogy "nem jott el az idejuk", nem az a baj hogy alapvetoen rossz otlet ...

On 2005-07-14, LGB <spam@lgb.hu> wrote:
>
> Azert eljohet meg a valtozas ideje ... Ugyanis a mikrokenel felepites
> alapvetoen lasabb ,ezen nem erdemes csodalkozni: egy monolitikus OS
> kernelben ott vannak "egy darabban" a cuccok idoveszteseg nelkul el lehet
> erni barmit. De itt arrol van szo hogy egymassal kommunikalo kulonallo
> processek vannak ha szabad igy nevezem hirtelen a dolgot. Viszont ahogy
> haladunk a szeeeeeep uj jovo fele, egyre nagyobb problema a security (es
> egyre kenyesebb lesz) az egyre gyorsulo hw-ek miatt a sw fejlesztok pedig
> regen mar nem a leggyorsabb stb megoldast preferaljak [mas kerdes hogy ez
> jo-e] mert mas szempontok (lasd: RAD) egyre dominansabba valnak. A nagyobb
> rendelkezesre allas is lenyeges.
>
> Nos, a mikorkernelek lassabbak, viszont jobban szeparalhato/ellenorizheto a
> kernelen beluli kooperacio, azaz biztonsagosabb lehet elvileg (nincs olyan
> hogy egy pointer rossz helyre mutat aztan atirsz veletlenul egy asmik
> memoriateruletet pl: mert igy max az egyik szerver szalhat el pl es nem az
> egesz monolitikus os kernel), az egyes szerverek online cserelhetoek, ujak
> indithatoak stb stb.

Hm, en ugy erzem mikrokernel lassusaga nem elsosorban vas szinten
manifesztalodik, hanem human -- fejlesztoi -- szemszogbol.

Jol kitalalni es implementalni es debuggolni a kommunikacios protokollt
nagyon nehez, ugy, hogy meg fenntarthato is legyen a dolog hosszutavon
(pl ne kottyanjon meg neki egy olyan valtas, mint Mach -> L4).

Aztan meg az is nehez, hogy az egyes szerverek altalanosan
implementaljak azt a protokollt. Ha tudod, hogy az ext2 fajlrendszered a
linux kernelhez irod, akkor az implementacio folyaman semmi masra nem
kell tekintettel lenned, mint a linux kernellel, az osszes szerencses
es szerencsetlen esetlegessegevel egyutt. Joval nehezebbnek erzem egy
pusztan a kommunikacios interfesz deklaracio alapjan mukodo ext2 fs
szerver megirasatm, ugy, hogy az mindenhol menjen, ahol az az interfesz
adott. (Valahogy nem hiszem el, hogy annyira szepen ortogonalisak
lennenek a dolgok, mint amikor az userspace-re irsz egy http szervert, a
http spec es a POSIX/SUSV3/... alapjan, es azt latod, hogy ha megirod
linux alatt akkor pikk-pakk BSD alatt is futni fog. Ez csak egy erzes,
szolj, ha hulyeseg.)

Cs.

Ironianak ok :-))

Az L4linuxnak lenne értelme, és nemcsak annyi, hogy más L4 alapú os mehetne párhuzamosan. Olvasd csak el a Drops képességeit. Real time alkalmazásoknál is a mikrokerneles felépítés a célravezető. A Darwin sem más, csak az Applenél Linux helyett FreeBSD húztak Mach felé. A Digital Unix is Mach (bár nem gnu mach :) mikrokernelre épül, ma tru64-nek hívják. Szóval egyáltalán nem értelmetlen az amit L4Linuxal csinálnak. Csak mint írtam, az alkalmazások többségénél jelenleg lassabb az L4Linux hagyományos társánál.

Na igen, de pont ez a jo is benne: egy ext2 filesystem implementacio pl a Linux kernelben gyakorlatilag mindent elerhet ami a kernelhez tartozik meg azt is amire pl Linus azt mondana hogy "ezt azert nem kene", meg hasonlok, ami viszont modot ad a "ganyolas" nevu eljarasra is, hogy mindenbe "beleusd az orrod". Persze nyilvan viszont a "masik veglet" is eleg nehez, amikor csak kommunikacios protokolokat hasznalhatsz meg ilyen abdsztrakt dolgokat. Tehat egyik eset se egyszeru, ez teny, meg masreszt nem is minden fekete vagy fehet, az is nyilvanvalo. De lehetne meg ragozni a dolgot eleg sokaig ...

Hat az imho agyuval a veregbe, realtime alkalmazasokhoz mas egyszerubb konstrukciok is elegesegesnek bizonyulnak ahol ugyanugy kvazi a linux kernel csak egy "process", es mellette futnak meg mindenfele RT taskok esetleg, a problema ezzel csak az, hogy a linux kernel alatt futo dolgok azt mondjak hogy "ez egy linux", de az RT taskoknak mar elegge keves kozuk van a linuxhoz, nekik kvazi teljesen mas a "velemenyuk" hogy mi is ez a rendszer. Mondjuk Drops-rol tul sokat nem tudok, szal arrol nem akarok hulyegeket irni :)