| MJesus | buenas |
|---|---|
| @garoeda | (log note: start translation) |
| @garoeda | ik wil iedereen welkom heten op de laatste presentatie van Umeet conferentei van diet jaar |
| @garoeda | s/diet/dit |
| @garoeda | het laatste event is een rondetafelgesprek over de 2.5 kernel |
| @garoeda | en we zijn verheugd enige tijd te kunnen lenen van dave jones, robert love, andrew morton en mogelijk cameo verschijningen van rik van riel, greg kroah-hartman, chris wright, pat mochel en anderen :- |
| @garoeda | even vermelden dat we vertalingen naar het nederlands hebben in #taee (bedankt garoeda) en naar het spaans in #redes (bedankt arador en de anderen) |
| @garoeda | davej: eens zien of ze kunnen volgen met 4-5 sprekers 8-) |
| @garoeda | dit gezegd zijnde, laat ons beginnen met wat algemene vragen |
| @garoeda | wat denken jullie dat de grootste vooruitgang gaat voor de gebruikers gaat zijn in de 2.5 reeks van kernels? |
| @garoeda | preempt |
| @garoeda | neenee, de VM |
| @garoeda | 1) verbeterd device beheer (wanneer het afgeraakt) |
| @garoeda | 2) minder latency bij veel writeout |
| @garoeda | het device management is belangrijk voor "grote" gebruikers, de latency voor desktops |
| @garoeda | in het algemeen is het beter de VM van de block I/O los te koppelen |
| @garoeda | het device management is ook nuttige voor "kleine" gebruikers, als ze willen weten welke USB drive waar hangt |
| @garoeda | ik herinner me gelezen te hebben dat een van marshall kirk mckusick doelen is de VM en het bestandssysteem gemerged te zien. wat denk je dat dit betekent voor een OS designer |
| @garoeda | dit is een goede vraag en een iets dat ons allemaal aanbelangt: <mulix>: wat denken jullie wat de grootste verandering gaat worden voor out-of-tree ontwikkelaars? |
| @garoeda | het betekent dat ze helemaal geintegreerd gaan worden, en in realiteit zijn ze ver hetzelfde. alles gaat door de VM, dus moeten ze nauw met elkaar verbonden zijn |
| @garoeda | antwoord op mulix: de vele API veranderingen, veel van hen zijn voor drivers |
| @garoeda | wat betekent de integratie van de VM en block IO voor applicaties zoals databases? |
| @garoeda | ik ben van plan geweest een hackers-eye-view te schrijven van mijn post-halloween document maar ik heb de tijd nog niet gevonden om iets samen te stellen |
| @garoeda | ik ga proberen een minimum te schrijven, het posten, en de anderen het dan laten uitwerken, zoals wat er gebeurde met de ander documenten 8) |
| @garoeda | de verwijdering van cli()/sti() en de veranderde locking regels gaan nogal wat out-of-tree code veranderen |
| @garoeda | vraag: zou het mogelijk zijn een snelle introductie te geven de sprekers? wat is hhun rol in de kernel ontwikkeling/gemeenschap |
| @garoeda | ja, voorstellingen :-) |
| @garoeda | andre is de IDE master |
| @garoeda | bacchus is de master van MIPS |
| @garoeda | ddub en gregkh doen LSM |
| @garoeda | gregkh doet USB |
| @garoeda | mochel doet device beheer |
| @garoeda | rml doet pre-empt |
| @garoeda | rml is een knappe jongen ;) |
| @garoeda | (stukje over het knap zijn weggelaten, conclusie: mochel en rml zijn alletwee knappe jongens) |
| @garoeda | vergeet akpm niet, die is gekend om alles te doen van tijd tot tijd |
| @garoeda | davej: in het laatste jaar heb ik nogal veel dingen gedaan, elementen van 2.4 forward geport vlak na de split, enige x86-54 dingen en voor de moment sta ik tot mijn knieën in agpgart |
| @garoeda | ontwikkeling/gemeenschap? |
| @garoeda | inderdaad, ik herken akpm nog steeds als een alias voor een kamer vol met hackers |
| @garoeda | haha, hij heeft zichzelf leren fork()'en zoals Alan |
| @garoeda | rml, iets wat je gemist hebt toen je aan het reconnecten was |
| @garoeda | ok, genoeg over onszelf - wars van mochel en zijn oorlogsverhalen over vietnam zijn we niet interessant..volgende vraag? |
| @garoeda | akpm: mijn geheim is drivers te vermijden ;) |
| @garoeda | rml akpm: heb jij geen netwerkdrivers onderhouden? :) |
| @garoeda | sarnold: je vertelde over unificaties tussen de VM en block IO |
| @garoeda | hoe gaat dit werken voor de database verkopers, die gewoonlijk ganse machines draaien alsof ze zelf het OS waren? |
| @garoeda | andre: een van de vragen die ik heb voor de mensen hier is hoe ze de grijze zone an afgeleide of 'pristine' drivers willen oplossen zodat meer mensen in het bedrijfsleven Linux kunnen gebruiken zonder een team rechtskundigen in te huren vanwege de grijsheid |
| @garoeda | gregkh loopt weg van deze vraag |
| @garoeda | andre verwacht hierdoor de doodstraf te krijgen |
| @garoeda | rml: ja, dat is nog altijd min of meer het geval, maar ik spendeer bijna geen tijd meer aan net-drivers |
| @garoeda | rml: O_DIRECT en raw I/O zullen gelukkig zijn denk ik, ze kunnen een groot stuk kernel vermijden als ze willen |
| @garoeda | gregkh: andre, we zijn ontwikkelaars, geen advocaten, alstublieft niet hier |
| @garoeda | andre: okay |
| @garoeda | rml: enkel technische vragen |
| @garoeda | hint: PnP |
| @garoeda | akpm: grote databases hebben de neiging om de ganse machine over te nemen, ze proberen de VM te vermijden of er afhankelijk van te zijn, zelfs van bestandssystemen |
| @garoeda | pnp dingen zijn de laatste tijd erg veranderd |
| @garoeda | sarnold: een ding dat ik gemerkt heb is de mensen zoals rml(robert love) vooral werken aan desktop reactiesnelheid problemen, zoals de pre-emptable kernel (om de latency te verminderen) |
| @garoeda | voor databases is direct-io critisch, en dingen zoals hugetlb pagina's en pagetable sharing |
| @garoeda | en de scheduler |
| @garoeda | ik denk niet dat er specifieke documentatie is over de PnP veranderingen |
| @garoeda | en andere mensen zoals wli (wiliam lee irwin) zijn vooral geinteresseerd in grote systemen, waar doorvoer het belangrijkste doel is |
| @garoeda | is er een goede menging tussen reactietijd en doorvoer voorzien in de 2.5 kernel? hoe is die in vergelijking met 2.4? |
| @garoeda | gregkh: jij hebt gewerkt met de pnp dingen, enig inzicht erin? |
| @garoeda | goede vraag, je moet een afweging maken |
| @garoeda | een van de grootste block veranderingen komt van Oracle, superbh |
| @garoeda | sarnold: 2.5 is vooral getuned voor reactietijden, dit betekent meestal een verhoogde doorvoer, maar soms ook niet |
| @garoeda | gregkh: ja, de pnp laag is grotendeels veranderd, maar sorry, geen documenten waar ik weet van heb |
| @garoeda | sarnold: andre: wil je meer vertellen over superbh |
| @garoeda | het is een manier om 10% io submissions in een batch te doen, en vermindert de bh overhead in 2.4 'by ab' (vertaler: rare zin) |
| @garoeda | in plaats van te werken met single sector/wait-for dingen, kan je een lijst iovecs batchen naar een blok en het laten rocken |
| @garoeda | het porten van de pm bits van 2.4 staat al enige tijd op mijn TODO, ik heb het opzettelijk weggelaten toen ik aan het forward porten was daar ik er nog altijd enige problemen mee had |
| @garoeda | is er een verband tussen superbh en benjamin's asynchrone IO? |
| @garoeda | niet dat ik kan zeggen, het eene is een submission proces en het laatste is een execution proces |
| @garoeda | davej: niet zeker, ik zou er mee moeten werken om het zeker te kunnen zeggen |
| @garoeda | er is een ding dat ik vooral frustrerend weet zijn voor de noden van de hoge doorvoer en hoge reactiesnelhei gebruikers is de nieuwe O(1) scheduler van ingo |
| @garoeda | davej: gebruikt het de pci_driver api? |
| @garoeda | welke problemen heeft de O(1) scheduler voor interactieve gebruikers, welke problemen heeft het voor hoge doorvoer gebruikers en wat denk je dat er gedaan kan worden om het te verhelpen |
| @garoeda | ik denk niet dat ze verbonden moeten zijn, zeker al niet op uniprocessor |
| @garoeda | de scheduler heeft schaalbaarheidsverbeteringen en heeft interactiviteit verbeteringen |
| @garoeda | het zijn de interactivity verbeteringen die nog niet volledig uitgewerkt zijn |
| @garoeda | Unix geeft traditioneel altijd voorkeur aan interactiviteit dan doorvoer in de scheduler |
| @garoeda | akpm: ik neem aan dat je geen fan bent van dingen zoals kautotuned die verschillende kernel paramters zou aanpassen afhankelijk van de gesampelde systeem statistieken, enige reden waarom er afkeur is voor die methode? |
| @garoeda | akpm: ik herinner me dat realtime-scheduled processen (SCHED_RR, SCHED_FIFO) een enorme latency ondervinden van de O(1) scheduler, zijn deze problemen gerelateerd met de interactivity verbeteringen? |
| @garoeda | nee, real-time taken worden niet beinvloedt door de interactivity estimator, het zijn "static priority" klassen |
| @garoeda | verder kan geen enkele niet-realtime taak zijn prioriteit verhoogt worden tot die van een real-time taak door de interactivity estimator |
| @garoeda | het probleem dat ik heb met alles wat de kernel tuned op een geobserveerd load pattern is dat het verkeerd gaat wanneer de load plotseling anders wordt |
| @garoeda | de enige real-time achteruitgang waarvan ik op de hoogte ben is op SMP, sinds we per-CPU runqueues hebben kan een realtime task 'starven' op een processor terwijl de andere in staat is het te draaien |
| @garoeda | zijn er andere dingen trager gewordden in 2.5 serie? is er iets dat sneller werkte op 2.4? |
| @garoeda | akpm was hier net naar aan het zoeken |
| @garoeda | zwane: ok, dit zou inderdaad niet werken voor realtime tuning en daardoor meer adaptief, maar we maken nu ook al de verkeerde beslissingen |
| @garoeda | sommige performantie achteruitgang is normaal tijdens de ontwikkeling |
| @garoeda | de meeste dingen zijn beter geworden (weinig echter) alhoewel we opzettelijk in sommige gevallen doorvoer benadeeldt hebben ten voordele van eerlijkheid |
| @garoeda | vraag: hallo ik zou de opinie van het panel willen weten betreffende MSFT's trusted computing environment die voor mij (als programmeur) wil zeggen dat hardware geen software zal draaien als die niet ondertekent is door een betrouwbare groep of MSFT. op welke manier gaat het de Linux gemeenschap en ontwikkeling beinvloeden? |
| @garoeda | akpm kan misschien vertellen over zijn recente ontdekkingen ivm 2.5 regressie? |
| @garoeda | zwane: rml: is het niet mogelijk een migratie te doen? of zou dat te duur zijn? |
| @garoeda | er gaat nog veel tuning gebeuren naar het einde toe van 2.5 en in het begin van 2.6 om de performantie te fine tunen |
| @garoeda | dit is gelijkaardig met ons tainting proces, we gebruiken het om te bepalen of iets aan echt aan de kernel ligt of een slecht binair monster |
| @garoeda | dat is waarschijnlijk zo, we zouden iets kunnen doen zodat we tenminste zeker zijn dat de rt-tasks eerlijk verdeelt zijn. de enige perfecte oplossing is een globale runqueue voor real-time tasks, zoals de O(1) scheduler oorspronkelijk had |
| @garoeda | gaat er iets in de kernel zitten dat de gebruikers zal teleurstellen in vergelijking met 2.4? |
| @garoeda | gregkh en manfred kunnen die vraag beter beantwoorden |
| @garoeda | niet echt, er zijn vertragingen maar die zijn miniem. de ergste zijn ten gevolge van de rmap toevoegingen aan de vm |
| @garoeda | voor sommige workloads die *veel* forking doen (zoals shell scripts) kan het tot 10% trager gaan |
| @garoeda | ik herinner me daniel philips die sprak over copy-on-write pagetables, zijn er enige inspanningen geweest om dit probleem op te lossen? |
| @garoeda | ik denk dat we dat kunnen terugrkijgen via pagetable-sharing code. ik denk er nog altijd over |
| @garoeda | ja, dat wekt allemaal al. maar in het geval van shell scripts, alle pagetables worden geschreven en gekopieerd in elk geval :( |
| @garoeda | heh :) |
| @garoeda | dat zou een een een randomnisatie vereisen of een analyse van libc en de programa mapping, niet? zou dat teveel TLB flushes veroorzaken? |
| @garoeda | betreffende de msft trusted computing dingen, ik kan niets zeggen, behalve dat mensen onderzoeken hoe het linux zal beinvloeden en hoe linux gaat draaien op die hardware |
| @garoeda | het zou een een extra tlb ingnag kunnen vereisen, waarschijnlijk is dat niet echt significant |
| @garoeda | *kuch* linuxbios *kuch* |
| @garoeda | een probleem dat ik me kan indenken met linuxbios is de afhankelijkheid van een specifiek moederbord model, is het design zodanig dat linuxbios of andere opensource bios projecten meer algemeen kunnen zijn? |
| @garoeda | van wat ik kan zien is dat je veel bord specifieke dingen moet weten. (zoals hoe de dram banken aangesloten zijn) |
| @garoeda | er zijn enige beanstigende gevolgen aan TCPA en opensource code, ook beschuldigingen dat het enforcable DRM is met een andere naam. het zal tijd nodig hebben eer het allemaal duidelijk wordt |
| @garoeda | vraag: waarom zit IPSec niet in de Linux kernel (of zit het in de laatste 2.5) |
| @garoeda | het zit in de nieuwste 2.5 |
| @garoeda | er waren wat probelemen met cryptograpy in de kernel maar die zijn al lang opgelost |
| @garoeda | http://lartc.org/howto/lartc.ipsec.html is een mini-howto om die dingen te doen werken |
| @garoeda | weet je of het werkt met de de FreeS/WAN userland tools, zoals de sleutel onderhandelings daemons? |
| @garoeda | de netwerk maintainers hadden enige problemen met kwaliteit van code/smaak en ze wilden veel doen op een andere manier...dus we hebben een redelijk nieuwe implementatie in 2.5 |
| @garoeda | het gebruikt een afsplitsing van de KAME tools voor zover ik weet |
| @garoeda | in feite hebben we een geheel nieuwe crypto laag in de kernel |
| @garoeda | (in feite, james morris, een van de auteurs van de crypto laag heeft een paar dagen geleden een presentatie gegeven op umeet :)) |
| @garoeda | sinds alles deze dagen modulair wordt,zouden we ook voor ipsec moeten beslissen of we het soft of hook doen en de offload naar de nics verwijzen |
| @garoeda | hoe ziet het met gebruiksvriendelijkheid voor de eindgebruiker?, iemand vroeg of supermount in de kernel zou komen, een ander vroeg of Oopses tijdens het mounten van cdroms minder gingen voorvallen |
| @garoeda | ik denk niet dat we supermount gaan zien |
| @garoeda | ik denk dat oopses tijdens het mounten minder gaan voorvallen naarmate de drivers beter worden, hopelijk hebben we vooruitgang gemaakt. oopses zijn nooit goed |
| @garoeda | hoe gaat het met async I/O, het staat als 'before 2.6' op Guillaume's lijst |
| @garoeda | AIO zit er nu in |
| @garoeda | maar supermount en devfs schijnen populair te zijn onder de sommige gebruikers, wat is he criterium om te beslissen of iets in de kernel gaat? |
| @garoeda | ik denk dat supermount 'niet populair genoeg' is voor iets dat compleet elegant is |
| @garoeda | Juan Quintela heeft het voorbije jaar veel tijd gespendeerd aan het opkuisen van supermount, en het zal nog veel werk nodig hebben om voorbij mensen zoals viro te gaan |
| @garoeda | ja, een groot obstakel is dat Al Viro de maintainer van de subsysteem is en zijn standaarden zijn *erg hoog* |
| @garoeda | Alan heeft een min of meer werkende hack gebruik makende van NFS over loopback |
| @garoeda | ik zou niet de mens willen zijn die supermount aan viro geeft |
| @garoeda | ISTR is ook helemaal userspace, wat leuk is 8) |
| @garoeda | wat denken jullie van de varieteit van kernel trees die er tegenwoordig is? teveel? niet genoeg? helpen ze onze World Domination Plans niet? |
| @garoeda | ik zou eraan willen toevoegen: is het wel waard om world domination na te streven? |
| @garoeda | ik denk dat de UL en RH trees tever van de mainline zijn afgeweken, we zouden harder moeten werken om de wijzigingen terug te krijgen |
| @garoeda | ik denk dat externe trees heel belangrijk zijn en nuttig wanneer de tree gemaintained wordt door een developer die tree gebruikt als test en er patches doorvloeien naar de mainstream |
| @garoeda | maar ik denk niet dat het serieuze problemen gebracht heeft |
| @garoeda | de meeste trees zijn voor merging doelen niet hoodzakelijk forks |
| @garoeda | bv, trees zoals 2.5-nm en 2.5-dj zijn zeer belangrijk |
| @garoeda | denk je dat RH's en UL's kernel maintainer s de verplichting hebben om de veranderingenterug aan de mainstream te geven? marcelo kan maar even snel mergen en het nog altijd een stable 2.4 kernel noemen |
| @garoeda | wel, bugfixen zouden snel naar marcelo moeten gaan, features zijn minder belangrijk |
| @garoeda | het zou ook het geval kunnen zijn dat er niet veel unmerged bugfixes zijn, ik ben niet zeker |
| @garoeda | maar de grootte van de diffs is een beetje verontrustend |
| @garoeda | ik las dat UL bijna 800 patches heeft, dat moet minder worden |
| @garoeda | akpm: moet naar een vergadering |
| @garoeda | davej gaat hiermaa akkoord, maar een groot deel van UL zal nooit de mainline zien, of is het een backport van 2.5 features 8) |
| @garoeda | een gelijkaardige vraag: zijn er plannen om Reiser4 te mergen |
| @garoeda | dat is volledig afhankelijk van Linux |
| @garoeda | reiser4 is veel code (rond de 2MB) |
| @garoeda | ik denk dat als het geen of weinig impact heeft op niet reiser4 specifieke code het gemerged zal worden |
| @garoeda | dat is veel code voor een bestandssysteem |
| @garoeda | maar ik heb het gevoel dat het te indringend is, zoals davej zei, 2MB is veel voor een bestandssysteem |
| @garoeda | het is veel te laat om drastische wijzigingen te doen, ik hoop dat Linus het niet doet als het zo is |
| @garoeda | er waren enkel 3 delen buiten fs/reiser4 die aangepast werden en viro, hch etc..hadden er geen bezwaar tegen al ik me het goed herinner |
| @garoeda | het is waarschijnlijk |
| @garoeda | hmm, goed |
| @garoeda | vraag: denk je dat de veranderingen die aan de kernel gedaan werden in de laatste ontwikkelingscyclus teveel complexiteit gaan toevoegen en zo de newbie of de kernel hackers afschrikken. of maken de api's het eenvoudiger en toegangkelijker? |
| @garoeda | dat is een goede vraag |
| @garoeda | sommige dingen zijn echt *ingewikkeld* geworden, ik hoop dat het geen newbies afschrikt |
| @garoeda | Linux is altijd verbazingwekkend eenvoudig in het design geweest |
| @garoeda | Larry McVoy is hierover begonnen op de OLS./Kernel samenkomst. de dingen zijn dezer *dagen* veel ingewikkelder dan toen wij begonnen |
| @garoeda | ja, de barriere om te beginnen is hoger geworden |
| @garoeda | om een specifiek antwoord te geven: de barriere is hoger geworden, geen twijfel. maar hopelijk niet genoeg om newbies af te schrikken |
| @garoeda | op hetzelfde moment zijn dingen geformaliseerd en geconsolideert in leukere API's |
| @garoeda | development -> feature freeze -> code freeze -> stable. |
| @garoeda | tussen feature en code freeze kunnen API's veranderen als het absoluut nodig is |
| @garoeda | heeft linus plannen voor een toekomstige code freeze? zijn deze realistisch |
| @garoeda | niemand mage denken dat kernel ontwikkeling/os design gemakkelijk is, maar de complexiteit moet niet nodeloos hoog zijn |
| @garoeda | ik herinner me niet dat hij hiervoor een datum gegeven heeft |
| @garoeda | ik denk dat goede programmeurs die OS theorie kennen zonder problemen kunnen beginnen |
| @garoeda | ik denk de eerste januari, zo zei hij op de cruise |
| @garoeda | ik denk dat hij zei 1 januari voor freeze en zomer 2003 voor de release |
| @garoeda | en ik denk dat dat doenbaar is |
| @garoeda | zou een code freeze werken in het linux ontwikkelings model? |
| @garoeda | we hebben al een code freeze gehad op het einde van de development reeks |
| @garoeda | hangt er vanaf, er is "code freeze" en er is "torvalds code freeze" |
| @garoeda | voor verschillende graden van vriezen natuurlijk :) |
| @garoeda | mijn belangrijkste probleem is, als developers over het algemeen in hun eigen tree werken , zouden ze problemen opmerken in een "frozen"' kernel? |
| @garoeda | Linux heeft gezegd dat ie "heel tevreden" is met 2.5, dus als geen kwaadaardige uitzonderingen of regressies ontdekt worden denk ik dat Linux kan zeggen "ok" |
| @garoeda | om eerlijk te zijn, Viro is een aardige jongen die geen zever aanvaardt |
| @garoeda | het grootste probleem nu dat 2.6 tegenhoudt is dat veel drivers nog kapot zijn |
| @garoeda | niets wat ik zei was negatief tegenover viro, hij is een verbazingwekkend programmeur met een goede smaak. ik zei alleen dat het moeilijk was om patches voorbij hem te krijgen |
| @garoeda | wat een goede zaak is |
| @garoeda | zou driver code uitgesloten worden van een cody freeze? |
| @garoeda | om terug in de maintainer lijst te geraken moest ik code geven aan Viro en dat was de test of ik terug het hoge niveau kon halen |
| @garoeda | sommige dingen zijn zo hard kapot dat het wel zo zal moeten zijn |
| @garoeda | de usb drivers zijn niet kapot, het is de scsi en block layer |
| @garoeda | en voor een zeer goede reden, als we allemaal die onverdraagzaamheid hadden voor cruft, welll... |
| @garoeda | en rare dingen zoals hamradio enzoverder |
| @garoeda | inderdaad |
| @garoeda | scsi heeft ook een recode nodig |
| @garoeda | wat zijn de veranderingen voor md en LVM in 2.5. wil iemand samenvatten? |
| @garoeda | ik denk dat deze vraag verloren is gegaan, kan gregkh eens samenvatten? |
| @garoeda | (onvertaalbaar: it need to try and model the effective state machines fuzzy of the bus-phase operations) |
| @garoeda | dm heeft de lvm code vervangen |
| @garoeda | lvm2 en evms zullen vooral userspace code zijn die de dm code in de kernel gebruikt |
| @garoeda | dit zou alle vreemdheden terug in de HBA drivers duwen en uiteinlijk tonen wie en en hoe de lelijkheid van de SCSI T10 groepen 'ends justify the means' model van hardware design |
| @garoeda | zal dat helpen? |
| @garoeda | betreffende de hamradio rommel, ik protesteer :) ik heb het maintainerschap overgenomen maar de schade repareren van vele jare niet maintainen duurt enige tijd |
| @garoeda | en ik heb me altijd afgevraagd waarom SCSI en IDE in verschillende subsystemen behandeld worden, doen ze niet dezelfde dingen? |
| @garoeda | Bacchus, je ben een dappere man 8) |
| @garoeda | ze doen hetzelfde, maar de manier waarop is vreemder dan je ooit wil weten |
| @garoeda | akkoord |
| @garoeda | over de 2.5 code freeze, is 2.5 klaar voor newbies om het zelf uit te testen. wat zou de beste manier zijn voor nieuwe gebruikers om 2.5 te testen |
| @garoeda | ik denk dat 2.5 stabiel genoeg is voor gewone testers ja |
| @garoeda | het vereist heel wat handjes vasthouden (ATA/ATAPI) en de ander vereist veel frustratie (SCSI et al) om in de goed fasen te geraken |
| @garoeda | ugh, modules |
| @garoeda | 2.5 werkt goed genoeg voor mij om het de hele dag op mijn desktop te gebruiken |
| @garoeda | oh ja, modules kunnen ongelukkig genoeg een probleem zijn |
| @garoeda | ik heb de ganse dag bugs gezocht in modules die verband hadden met agp, om eerlijk te zijn met rusty waren ze allemaal mijn fout |
| @garoeda | maar als je dat allemaal kan overleven (of de kernel statisch compileren zoals echte hackers <g> ben je in orde) |
| @garoeda | de nieuwe module dingen doen extra dingen die de oude niet deden (zoals __init secties vrij maken) |
| @garoeda | maar de module verandering kwam te laat |
| @garoeda | ja, dat was zo, misschien te laat |
| @garoeda | inderdaad, heel laat |
| @garoeda | is dat zo? tiens, dat wist ik niet, leuk |
| @garoeda | ik heb het de harde weg ondervonden |
| @garoeda | maar ik denk dat de problemen in de nieuwe module code snel opgelost gaan worden |
| @garoeda | ik heb de idee gehad om vergif toe te voegen aan he vrijmaken van __init voor een tijdje |
| @garoeda | zal gcc 3.2 officieel ondersteunt worden binnenkort? |
| @garoeda | ik denk dat dat al zo is |
| @garoeda | als er mensen bugs raporteren en ze gebruikten de intel compileren denk ik dat er hen gevraagd zal worden om gcc te gebruiken en de bug te herhalen |
| @garoeda | enkel oude mensen zoals akpm die weigeren egcs achter te laten gebruiken geen gcc 2.96 of niewer |
| @garoeda | ik heb geen problemen met gccc 3.2 |
| @garoeda | voor we memory gaan vrijmaken, memset het met illegale instructies. als we dan een oops krijgen zien we het patroon |
| @garoeda | de compiler is voortdurend trager geworden sinds egcs 1.1 en dat is een reden waarom ik er bij blijf |
| @garoeda | zijn er problemen omdat de kernel zo nauw verbonden is met gcc |
| @garoeda | niet van mij 8) |
| @garoeda | ja, het is enorm traag, dat is waarom akpm niet verandert |
| @garoeda | het zou oopsen wanneer iets ander probeert naar dat geheugen te springen |
| @garoeda | voor de moment raken we meestal weg met het springen naar __init sections, aangezien die ram nog niet gealloceerd is en nog altijd de oude code bevat |
| @garoeda | er zijn veel device id tabellen gemarkeerd als __init ;) |
| @garoeda | heft er iemand plannen om de kernel documentatie te updaten tijdens de code freeeze die al dan niet doorgaat op 1 januari? :) |
| @garoeda | lijkt als iets voor Greg en hotplug |
| @garoeda | TuX is voor Ingo terwijl ie bezig was de threading dingen te doen voor zover ik weet |
| @garoeda | opmerking: ik werk aan het netwerk document van lkdp (linux kernel doc-n project) en gebruikt 2.4.18/19 ervoor. heeft de netwerkcode veel veranderingen ondergaan in 2.5.x? |
| @garoeda | het gerucht gaat dat ie de bedoeling had het in 2.5 te krijgen maar de feature freeze was eerst |
| @garoeda | zit de nieuwe threading in 2.5 of in een secundaire tree? |
| @garoeda | well, er zitten nieuwe dingen in zoals de ipsec stukken, de stackable routes ook |
| @garoeda | het is allemaal mainline, je hebt de nieuwe glibc/ntpl nodig om er echt voordeel uit te kunnen halen |
| @garoeda | de nieuwe threading codee zit in 2.5 nu |
| @garoeda | en de glibc dingen zoals NTPL zitten in glibc 2.3 |
| @garoeda | alhoewel ze niet per default gecompileerd worden |
| @garoeda | vraag: wat is de O(1) scheduler nu juist? |
| @garoeda | sommige van de verbeteringen beinvloeden ook de bestaande userspace threading |
| @garoeda | het is een process scheduler, dat betekent dat het beslist welk proces de volgende keer mag draaien |
| @garoeda | Ingo schreef hiervoor een mooie samenvatting: http://www.codemonkey.org.uk/post-halloween-2.5.txt |
| @garoeda | de O(1) wil zeggen dat het werkt in constante tijd, het neemt dus dezelfde tijd om te beslissen welk proces je gaat draaien, onafhankelijk van het aantal processen (probeer dat eens uit te vinden) |
| @garoeda | maar geen andere design/groote veranderingen? de normale code opkuis en verbeteringen etc..? |
| @garoeda | dat is wat ik herinner ...sommigen zeggen dat netwerk een beetje voorloopt op de rest van de kernel |
| @garoeda | het doet dit door een bitmap van prioriteiten te implementeren, dus het weet wat het runnable proces met de hoogste prioriteit is door naar de eerste set van de bitmap te kijken |
| @garoeda | NAPI ? |
| @garoeda | well, het zit ook in 2.4, niet? |
| @garoeda | dus moet het niet over alle processen lopen om het belangrijkste te vinden |
| @garoeda | ik ben het verloren, eerst zat het erin, dan eruit, dan zei iemand dat het terug was |
| @garoeda | dat is de basis, maar er zijn veel andere andere algoritmen en ze zijn allemaal O(1)..veel te discussieren dus |
| @garoeda | heh, ok |
| @garoeda | het is mogelijk dat je NAPI ook als update wil zien |
| @garoeda | de agp problemen in mainline waren mijn fout, het zou ok moeten zijn de volgende keer dat Linux een pull doet |
| @garoeda | NTPL thread support is er om POSIX threads te helpen ondersteunen, is de linux kernel naar volledige ondersteuning van POSIX of Single Unix Specification aan het gaan, of een ander verzameling specificaties |
| @garoeda | het zou geen lockups mogen veroorzaakt hebben, dat is waarschijnlijk een DRM specifiek probleem ipv agpgart |
| @garoeda | ik denk dat ebtables er ook is ingegaan |
| @garoeda | ebtables? |
| @garoeda | netfilter for bridging |
| @garoeda | enkel waar we denken dat de standaard goed is |
| @garoeda | NTPL is meer que performantie dan compliance, alhoewel het de compliance verbeterdt in enkele gevallen |
| @garoeda | well, het testen van drivers kan misschien beter onder vmwae gedaan wordden, maar uml debuggen is gemakkelijker |
| @garoeda | tenzij er ander technologische punten te bespreken zijn kunnen we overgaan tot meer filosofische kwesties |
| @garoeda | filosofisch? moet ik bier gaan halen? |
| @garoeda | als een kernel oopst in een stoffig hoekje van een datacenter waar je het kan zien, heeft het dan echt geoopsed? |
| @garoeda | davej zei al eerder dat sommige IPSec code van de KAME projecten genomen is |
| @garoeda | hoe zit het met het delen tussen de Linux en BSD kampen, en zou er meer moeten zijn? |
| @garoeda | ik kijk persoonlijk even naar wat ze doen om de zoveel maanden, naar de dingen die me interesseren |
| @garoeda | soms liggen zij voor, soms wij , maar het is altijd interessant |
| @garoeda | de AGP herwerking in 2.5 is gelijkaardig aan wat zij al een tijdje hadden |
| @garoeda | bv drivers per chipseet ipv een monolitische blok |
| @garoeda | ik heb gesproken met FreeBSD mensen over hun preemptive kernel (die een feature zou moeten zijn in 5.0) |
| @garoeda | in het algemeen waar licentie incompatibiliteit of andere problemen code sharing verhinderen spreken wij en de BSD mensen met elkaar |
| @garoeda | ik volg hun scheduler werk,, alhoewel zij afwijken van dingen waar ik het mee eens ben of waar de gemeenschap het over eens is (bv KSE die de klassieke "scheduler activaties" zijn) |
| @garoeda | maar ik volg de BSD dingen, ik denk dat we een beetje geleerd hebben van hun VM |
| @garoeda | ja, ik denk dat het nuttig is, ik volg trustedbsd graag |
| @garoeda | wat met Plan9, EROS, Wndows? |
| @garoeda | ik heb niet veel tijd gespendeerd met naar andere BSD's te kijken, enkel FreeBSD |
| @garoeda | ik heb niet echt gekeken naar Plan9 of EROS. Plan9 heeft enkele interessante design keuzes |
| @garoeda | ik heb enkele tests van windows gelezen |
| @garoeda | zelfs de NT kernel laat te wensen over, om eerlijk te zijn |
| @garoeda | hmm, enige plannen ivm role based access control mechanisms? |
| @garoeda | ze doen enkele vuile dingen om process starvation en prioritiy inversie te voorkomen |
| @garoeda | ja, het lsm project werkt aan een generisch access control framework |
| @garoeda | linux spinlocks en semaforen schijnen gedesigned te zijn om simpel te zijn, heeft linux daardoor ook last van verschrikkelijk problemen of is eenvoud een performantie winst |
| @garoeda | vooral spinlocks zijn een performance voordeel |
| @garoeda | i hou niet van bloatad locking (bv Solaris stijl locking) |
| @garoeda | het kan gebruikt worden voor role based access control |
| @garoeda | dat is het best feature van hun locks |
| @garoeda | wat is de roadmap voor generische access controle mechanismen? |
| @garoeda | verleden weekend gaf alan cox een presentatie die het belang benadrukte van code grootte en cache problemen. zijn er effors om de layout van kernel structuren te optimiseren zodat ze in de cache lijnen passen. enig systematisch testen met verschillende compiler flags? |
| @garoeda | de primaire focus is mergen met de mainline |
| @garoeda | dit houdt consolidatie in en opkuiswerk. dan meer modules gebruiken |
| @garoeda | ik denk veel ja, misschien teveel gebruik van cache-line-aligning |
| @garoeda | we moeten kijken aar de cache footprint in 2.5 omdat het zeker meer is geworden |
| @garoeda | ik denk dat je moet opletten voor teveel micro optimisaties, het kan niet op alle architecturen werken etc.. |
| @garoeda | dat zijn al die preempt_enable() |
| @garoeda | de dcache locking veranderingen zijn een goed voorbeeld van een algoritmische verandering om cache trashing te verbeteren |
| @garoeda | (de mensen stoppen even om de vertalers rust te gunnen, davej opport om preemptable vertalers te gebruiken) |
| @garoeda | iets wat mulix vroeg en wat ik graag zou weten: welke boeken raadt je aan om te lezen? :) |
| @garoeda | om te programmeren of voor het plezier? |
| @garoeda | technische boeken: de mindshare boeken |
| @garoeda | voor het plezier: romantiekboekjes |
| @garoeda | een goed boek is "UNIX Systems for Modern Architectures" by Curt Schimmel |
| @garoeda | zelf als werkt curt voor SGI? :) |
| @garoeda | ja, het is een echt goed boek |
| @garoeda | desondanks het een microsoft boek is, 'writing solid code' is een van mijn favorieten en het is verrassend goed geschreven |
| @garoeda | curt beschrijft ook architecturen zoals de i386 |
| @garoeda | alles van Stevens is ook heel goed (maar niet direct gerelateerd met kernel programeren) |
| @garoeda | "UNIX Internals: The New Frontiers" is ook heel goed |
| @garoeda | het ia64 kernel boek is ook heel goed, ik ben het beginnen lezen maar heb het nog niet uit |
| @garoeda | besprekingen over het reverse mappen van VM's , kernel preemption, SMP optimisatie etc.. het is een collectie van geavanceerde UNIX dingen |
| @garoeda | waar begint een newbie het beste mee? de laatste kernel of een historische? |
| @garoeda | ik ben met een snapshot begonnen en nooit teruggegaan |
| @garoeda | ik denk dat werken aan de huidige (2.4 of 2.5) goed is |
| @garoeda | wees vastberaden en *lees* en *schrijf* code |
| @garoeda | ik raadt meestal kernels aan die al beschreven zijn door literatuur om mee te leren |
| @garoeda | terwijl een hele hoop boeken meer concentreren op oudere versies zijn het vooral de concepten die je moet verstaan ipv de code |
| @garoeda | de code begrijpen helpt je ook van tijd tot tijd :-) |
| @garoeda | denk je je dat bach's 1984 (of 1986) boeken een goede introductie zijn? :) |
| @garoeda | titel? |
| @garoeda | ik lees dat boek nu, eigenlijk |
| @garoeda | rml heeft gelijk, je kan de ganse dag code lezen en niets leren. wanneer je echt iets gaat veranderen dat je start te leren. omdat je *moet* |
| @garoeda | design van het Unix Operating System denk ik |
| @garoeda | niet gelezen |
| @garoeda | het is een oud SvR2 boek |
| @garoeda | er zijn veel oude manuals waar ik nooit tijd voor had om ze te lezen. misschien zou ik een leesdag of twee moeten plannen per maand |
| @garoeda | good idee |
| @garoeda | ok, we zijn nu al een uur of twee bezig...dus ik ga nog een extra vraag stellen en dan is het vrij aan iedereen om vragen te stellen en te beanwoorden voor zij die er nog tijd voor hebben |
| @garoeda | mijn laatste vraag: is het werken met Linux nog altijd fun? met de nieuwe grote bedrijven die nu voor linux werken, is het nog fun als job en als hobby? |
| @garoeda | het is zowel mijn job als hobby en als het mijn job niet was zou het nog altijd mijn hobby zijn |
| @garoeda | het is nog altijd fun, ik denk dat allen die er betaald voor worden realiseren hoeveel geluk ze wel hebben |
| @garoeda | ik heb altijd gezegd dat ik ging stoppen de dag dat het geen fun meer was. betaald worden om het full time te doen was alleen maar een bonus |
| @garoeda | ik zou het kernelnewbies project willen vermelden als een goede manier om mensen te helpen leren hoe ze voor de linux kernel moeten programmeren |
| @garoeda | kijk op http://www.kernelnewbies.org voor meer informatie :-) |
| @garoeda | ik zou akpm, andre, rml, davj, mochel, gregkh, cdub en bacchus willen bedanken om tijd vrij te maken om met ons te spreken :) |
| @garoeda | ook een dankjewel voor de vertalers |
| @garoeda | :) |
| @garoeda | (log note: end of presentation) |