Deel 1 van een interview met Francisco Franco, de ontwikkelaar van Franco Kernel en andere applicaties voor veel verschillende apparaten.
Ik had onlangs het genoegen de man achter een van de populairste Android-kernels ooit te interviewen, de Franco Kernel. Momenteel is de kernel beschikbaar op veel verschillende apparaten, waaronder verschillende Nexus- & OnePlus-toestellen en de Google Pixel / Pixel XL.
In dit deel praten we over Francisco Franco's reis naar kernelontwikkeling en zijn mening over de veranderingen die Android door de jaren heen heeft ondergaan.
Ik ben Adam Conway hier op XDA om Francisco Franco, ontwikkelaar van de Franco Kernel, te interviewen! Wil je jezelf voorstellen?
Natuurlijk, mijn naam is Francisco, zoals je net zei, en ik denk dat ik al 1 miljoen jaar op XDA zit! Heb van alles gedaan. Kernels, apps, en de laatste tijd ben ik wat meer verslapt aan kernels omdat het na een tijdje vermoeiend wordt, maar ik ben nog steeds op volle sterkte op de meeste van mijn apparaten.
Oké, dus ik denk dat veel mensen bekend zijn met je werk, maar veel mensen zouden niet bekend zijn met de werkelijke persoon achter het werk. Dus ik neem aan dat je echt enige ervaring hebt met kernels? Zoals elke graad in computerwetenschappen of iets dergelijks vooraf?
Ik ben altijd gepassioneerd geweest door computers, zoals elk kind tijdens het opgroeien, denk ik. Nadat ik 18 was geworden, besloot ik net als iedereen naar de universiteit te gaan, en ik denk dat ik dat ook deed computerwetenschappen of zoiets, maar na een jaar of zo kwam ik erachter dat dit niet mijn passie was over. Na dat jaar begonnen mijn verwachtingen laag te worden omdat het allemaal gepraat was en geen actie, en dat was ik ook Ik begon me te vervelen – niet omdat ik beter was dan wie dan ook, ik was gewoon gemiddeld – maar de eigenlijke disciplines waren niet precies wat ik wilde. Dus ik sprak met mijn ouders, en zij wisten dat ik daar niet zo blij mee was. Tijdens Kerstmis 2010 kreeg ik mijn eerste Android-telefoon. Een LG P500, dat is een budgettelefoon, heel goedkoop, maar ik wist dat er Linux op draaide, en mijn favoriete discipline op de universiteit was computerarchitectuur of zoiets, besturingssystemen. En we leerden een beetje shell en praatten een beetje over de Linux-kernel, en wat dan ook maakte deel uit van de kernel en alle connectiviteit in de kernel, en het eigenlijke besturingssysteem, en zo was fascinerend voor mij. En toen begon ik samen met een vriend de Linux-kernel voor mijn oude laptop opnieuw op te bouwen. We hebben onze laptops daarbij wel 100 keer gecrasht, maar we hebben door het proces geleerd. En toen begon ik met mijn LG te spelen, en ik denk dat het eerste wat ik deed was proberen wat meer prestaties te leveren, omdat dat apparaat eigenlijk behoorlijk waardeloos was. Dus het beste wat ik kon doen was gewoon de standaard Linux-kernelparameters doorlopen voor de feitelijke situatie geheugenbeheer en zo, en probeer gewoon iets beters te vinden dan wat al was daar. Ik heb me toen een beetje vermaakt.
Ik denk dat ik dit nog niet eerder heb verteld in eerdere interviews, maar destijds gebruikte dat apparaat een oud bestandssysteem genaamd YAFFS - dat betekent Yet Another Flash Bestandssysteem, maar het was behoorlijk traag toen we probeerden te mounten als een door RAM ondersteunde wisselschijf, dus ik herinner me de details niet, maar we deden allerlei verschillende experimenten daarmee en uiteindelijk hebben we de Dalvik bovenop het geheugen-RAM gemonteerd dat bij elke herstart opnieuw moest worden opgebouwd, omdat, zoals je weet, RAM elke keer verdwijnt tijd dat we opnieuw opstarten. Maar het openen van applicaties en het uitvoeren van benchmarks ging aanzienlijk sneller, dus we waren blij. Dus daarna begon ik wat dieper te gaan en te proberen de kernelbronnen van LG voor het apparaat te compileren, en ik maakte allerlei slechte oordelen en allerlei fouten - Wi-Fi-netwerk, wat dan ook - alles wat je maar kunt bedenken van iemand zonder ervaring. Dit was leuk, ik heb veel geleerd. Ik denk dat ik na een jaar of zes maanden wat meer gefocust was, en ik een beetje beter wist wat ik moest doen om de downloads te krijgen. Dat is wat we uiteindelijk allemaal willen. Daarna slaagde ik erin wat donaties te krijgen en over te stappen naar andere apparaten. Ik vermoed de Nexus S, daarna de Galaxy Nexus en na die periode slaagde ik erin mijn eerste app uit te brengen. Ik denk dat ik heel veel geluk heb gehad en dat ik mezelf heb kunnen financieren door nieuwe apparaten te kopen, en vanaf dat moment is het ontploft. Dus ik denk dat ik uiteindelijk alles te danken heb aan, ik zou niet XDA zeggen, maar het platform die XDA ons biedt.
En de gemeenschap erachter en zo.
Ja ja, ik bedoel het platform, dat is de community en de daadwerkelijke forums. Voor iedereen die luistert: dit is geen betaalde sponsor of zoiets. Ik word niet betaald om dit te zeggen, het is gewoon waar!
Er is geen video, de mensen zien niet dat het pistool op je hoofd gericht is, het is oké.
Hahaha, ja, maar iemand zal zeggen dat ik betaald word om dit te zeggen, dus ik zeg het gewoon! Maar ja, ja, het is voor mij een geweldig platform geweest om coole dingen te bouwen, veel te leren, ik heb daar alles geleerd door vooral fouten te maken en tijdens het leren doe ik nog steeds een groot deel van de problemen. Ik heb mijn Xiaomi Redmi Note 3 vernietigd, de bootloader is zojuist vernietigd. Dus ik moet hem opnieuw verbinden met mijn Windows-computer die daar achterin staat en moet alles opnieuw flashen en hij staat hier al drie maanden. Ik krijg allerlei haat van iedereen omdat ik geen aandacht besteed aan dat apparaat, en dus maak ik nog steeds [fouten], denk ik, dus zelfs na al die jaren valt er nog steeds iets te leren en ik heb het geluk gehad dat ik deze reis heb meegemaakt en het is geweldig.
Nou, ik denk dat, aangezien je begon met de... LG P500 was het?
Jaaa Jaaa.
Hoeveel jaar geleden was dat? Omdat dat rond de originele versies van Android moet zijn geweest, toch? In de buurt van Froyo of zoiets?
Ja, dat werd met Froyo meegeleverd en een paar maanden later werd het geüpgraded naar Gingerbread. Dat apparaat was volgens mij 2010, begin 2011, waarschijnlijk eerder. Ik weet dat mijn account op XDA in december 2010 is aangemaakt, maar ik had het apparaat al eerder. Dus ik denk waarschijnlijk rond die tijd, ja.
Hoe is Android sindsdien qua prestaties geëvolueerd? Hoe is het bijvoorbeeld voor jou veranderd toen je kernels schreef en nu? En ik veronderstel wat uw mening is over de veranderingen.
Qua kernel denk ik dat we zijn geëvolueerd met de eigenlijke Linux-kernel en alle veranderingen die het Android-team eigenlijk wilde implementeren voor een bepaalde Android-release, dus dicteren ze de meeste speciale functies die de kernel zal hebben, gebaseerd op wat ze willen verschepen. Maar ik denk dat daadwerkelijke prestaties, meer cores, eigenlijk veel helpen, omdat je daar toen geen echte manier voor had verplaats deze thread (sic), of stel netwerkverzoeken voor via een achtergrondthread, of op zijn minst in realtime draadsnijden. Ik denk dat dit de grootste verandering door de jaren heen was, dat je meer manieren hebt om je werk te spreiden, en dat Android niet alleen maar trager wordt omdat iedereen dat kleine beetje CPU-aandeel probeert te pakken. Meer dan wat dan ook denk ik aan multi-core en echte multi-threading, ondersteund door Linux. Ik dacht dat dat de grootste verandering was.
Ah oké, dus wat is jouw mening over HMP versus EAS? Omdat EAS uiteraard alleen nieuw is en slechts op een paar apparaten wordt gebruikt - alsof je een Google Pixel gebruikt, toch?
Ja, momenteel gebruik ik een Galaxy S8, maar ik heb ook een Pixel. Ik ken beide niet zo gedetailleerd, het zijn gewoon verschillende implementaties van hoe een apparaat met meerdere clusters zou moeten handelen op basis van wat er op bepaalde momenten op het apparaat gebeurt. Het is behoorlijk moeilijk om twee verschillende clusters met twee verschillende energieverbruiken te gebruiken. Je moet voldoen aan de verwachtingen van taken die op en neer bewegen, en daar is een latentie bij betrokken. HMP was de eerste echte implementatie van een echte multi-geclusterde architectuur voor ARM, want als ik het me goed herinner, had Samsung, voordat HMP in de echte wereld werd gebruikt, een initiële implementatie waarbij u ofwel de eerste vier kernen gebruikte, zoals kernen met laag vermogen, of vier krachtige kernen, maar deze draaiden nooit op dezelfde tijd. Maar daarna waren de kernen met de HMP op elk moment klaar om te worden gebruikt en werden de taken gewoon van het ene cluster naar het andere verplaatst en omgekeerd, en dat werkte uit, maar je had niet zoveel informatie van de planner om dit aan de gouverneur te laten zien om daadwerkelijk te beslissen welke frequentie daarbij zou worden gebruikt specifieke tijd, dus je moest proberen te begrijpen wat er in [ongeveer] 20 seconden gebeurt, en dan, op basis van wat daar gebeurde, besloot je wat je moest doen. Doen. Bij EAS gaat het meer om begrijpen wat er in de toekomst gaat gebeuren en om in realtime beslissingen te nemen op basis van het uitgangsvermogen van elke kern, en dan zijn er een heleboel berekeningen en ingewikkelde dingen in de achtergrond
Zoals energiemodellen enzovoort om dit allemaal te ondersteunen.
Ja, dat denk ik wel, het is nogal ingewikkeld. Ik ken niet alle details. Ik heb een aantal documenten gelezen, maar het is behoorlijk ingewikkeld en het is niet alleen maar een schakelaar aanzetten en dat gereed hebben voor gebruik. Ik krijg die vraag vaak: kun je EAS op de XYZ-telefoon implementeren? Mijn antwoorden zijn altijd “Het is niet aan een knop draaien, zo is het niet. Er was een heel team van Googlers en jongens van Linaro voor nodig om het te implementeren dat en je moet dingen verplaatsen, dingen doen, dingen testen en dat is gewoon te veel werk en gedoe Blind" en... ja. Het is moeilijk.
Dus je moet precies weten wat je doet, het is geen eenmanszaak?
Ja, je moet weten wat je doet, iedereen kan de patches kiezen en ze samenvoegen, maar daadwerkelijk testen en ervoor zorgen dat het correct werkt en dat je een goede machine nodig hebt om het stroomverbruik van elke component te detecteren en er zijn een aantal tabellen in de kernel waar je de kracht van elke kern kunt schrijven, en op basis daarvan zal de code beslissen wat te doen Doen. Het is behoorlijk ingewikkeld. Ik denk niet dat dit een definitieve oplossing is voor alle problemen, maar het is absoluut de beste die we op dit moment hebben.
Dus jij ziet het als een verbetering?
Ja zeker, mijlen mijlen ver weg. Het is een duidelijke verbetering ten opzichte van HMP of welke andere architectuur dan ook, want als je begrijpt wat er in de toekomst gaat gebeuren, kun je veel sneller reageren op elk verzoek of wat er ook op het apparaat gebeurt, daarom is de Google Pixel zo snel en zo soepel, omdat alles bijna in echte tijd. Het verplaatst de frequenties op en neer, wat de gemakkelijkste manier is om aan de prestatieverwachtingen te voldoen.
Ik denk dat als er in de toekomst meer adoptie van EAS plaatsvindt, hoe denk je dan dat dit je eigen ontwikkeling met betrekking tot kernels zal beïnvloeden? Zou u nog steeds bij HMP blijven of zou u kiezen voor reeds uitgebrachte energiemodellen? Op de OnePlus 3 hergebruiken [ROM-ontwikkelaars] bijvoorbeeld het energiemodel van de Google Pixel voor EAS. Zie jij jezelf zoiets doen?
Ik zal dat waarschijnlijk niet doen. Als het apparaat om te beginnen niet met EAS wordt geleverd, zal ik het waarschijnlijk op geen enkele manier of in welke vorm dan ook implementeren, omdat zoals ik al zei, het is een behoorlijk langdurig proces en niemand bij XDA weet het beter dan al deze ingenieurs, dus we proberen gewoon voor God te spelen, denk ik.
Wat dat betreft, als we het hebben over de toekomst met Android en kernels, wat is dan uw mening over de recente Android Oreo-release? Vindt u de veranderingen goed? Heb je naar een van de nieuwe kernel-commits gekeken?
Er waren niet zoveel veranderingen aan de kernelkant van de Nexus 6P en de Nexus 5X, alleen hier en daar kleine verbeteringen. Op de Google Pixel waren ze bezig met het herhalen van de EAS-implementatie, en ze hebben enige tijd besteed aan het verbeteren van de mapsectie, omdat de map nu, samen met Project Treble, het is alsof je verschillende pakketten opsplitst, dus ze moeten 50 of 100 verschillende patches doorlopen om de map te verbeteren en deze in verschillende pakketten op te splitsen processen. Verder was het gewoon normaal werk voor een grote release. Als er een nieuwe platformrelease is, rommel je meestal niet zoveel met de kernel, omdat je met de kernel heb je eigenlijk veel QA nodig, als je soms iets verandert, hoor je dat het iets in een ander beïnvloedt subsysteem. Dat is wat ze meestal doen, daarom heb je geen kernelversie-hobbel tussen platformupgrades. Het is gewoon veel werk. Meestal niet de moeite waard, maar ja, het waren vooral bindmiddelen, een klein beetje van de planner en de gebruikelijke beveiligingsoplossingen. Ik heb ze allemaal doorgenomen, maar niets sprak me echt aan. Mijn aandacht werd alleen op de map gevestigd.
Ah oké, dus eigenlijk gewoon de standaard dingen.
Ja, ze zijn behoorlijk ingewikkeld en vraag me niet om details!
Dit is een heel ander onderwerp. Wat is jouw mening over F2FS versus ext4? Omdat je zou zien dat veel mensen zullen zeggen dat F2FS onstabiel is en dergelijke, en problemen veroorzaakt,Ik vraag me gewoon af wat jouw mening erover is.
Ik weet ook geen details, omdat bestandssystemen behoorlijk moeilijk zijn, er zijn hier en daar veel bewegende delen. Ik citeer alleen een Google-ingenieur die zegt dat F2FS op basis van hun test niet sneller presteert dan ext4, en bovendien wanneer ze waren dingen aan het testen voor de Google Pixel, F2FS bood geen ondersteuning voor... Ik denk dat het versleuteling van bestandsblokken was, terwijl ext4 voor ondersteuning Het. Dus dat alleen al betekent: schrap het gewoon. Je moet over twee dingen nadenken: er wordt al zo'n 20 jaar aan ext4 gewerkt met heel veel slimme ingenieurs van verschillende bedrijven en ze weten wat ze doen. F2FS werd, als ik het mij goed herinner, geïmplementeerd door Samsung. Het is een vrij nieuw bestandssysteem, dus zulke ingewikkelde dingen hebben tijd nodig om te verbeteren en te herhalen, net als jij kunnen zien aan het Apple-bestandssysteem dat zojuist op iOS is uitgebracht, en ze gaan hetzelfde doen voor Mac Besturingssysteem. Dingen kosten tijd, je hebt een enorm team nodig om deze dingen correct te doen. Ik ben een groot voorstander van "als het werkt, raak het dan niet aan" en wat we nu hebben - het werkt, en ik denk niet dat het prestatieproblemen oplevert, dus ik zie geen reden om rotzooi ermee.
Ah oké, dat is eerlijk genoeg! Hoe zit het met SDCardFS wordt overgeschakeld van FUSE? Wat zou jouw mening daarover zijn?
Dat gebeurde omdat het oudere FUSE-bestandssysteem een van de ergste dingen was die op Android gebeurden. De prestaties waren verschrikkelijk, er waren veel systeemoproepen tussen de kernel en de gebruikersruimte en nu met SDCardFS is het goed gedaan. Het is een normaal bestandssysteem om hiermee om te gaan. Nogmaals, ik ken de details niet, omdat het heel ingewikkeld is, maar wat ik heb gelezen en gezien en gehoord van verschillende podcasts van het Android-team, het loste in principe alle problemen met de oude op systeem. Dat was behoorlijk verschrikkelijk, de prestaties waren verschrikkelijk.
Bekijk deel 2 door op deze knop te klikken!