Microsoft bygger in Ubuntu i Windows 10

Ersättare till gamla Microsoft POSIX subsystem från tidigare Windows (NT, 2000)? Det som ersattes av SFU/SUA och Interix helt i och med XP. De går alltså tillbaka till rötterna. Detta har funnits i NT-kärnan tidigare. Det är inget revolutionerande. Det är intressant att de kan köra Ubuntus ELFs däremot. Det är förmodligen inte mycket mer än det var förr i och med att de inte siktar på att kunna köra en komplett user-land inklusive grafiska program och knappast siktar på att man kan blanda POSIX och Win32. Cygwin har fortfarande nytta alltså. MSYS/MinGW64 lika så. Eller vad säger du @Yoshman?

Hur som blir intressant att läsa mer om när det lanseras.

Det är inte en direkt ersättare för SFU/SUA, vad man gör nu tar det hela betydligt lägre mot att vara en "riktig" Linux. Vet inte hur mycket detta går att förenkla, men ska försöka göra det så enkelt att alla som förstår grunderna i programmering och OS-design ser skillnaden.

Låt oss studera ett anrop till open(), ett anrop som i Linux implementeras av ett standardbibliotek vid namn glibc. Hela denna diskussion förutsätter också att vi kör på en x86_64 CPU (namn på register och exakt vad som sparas i vilket register skiljer sig mellan olika CPU arkitekturer och även mellan 32-bit och 64-bit). Det enda glibc i praktiken gör är att anropa Linux-kärnans systemanrop nummer 2 som i kärnan hanteras av sys_open() men det behöver user-land överhuvudtaget inte veta, enda den måste känna till är att första argumentet för ett systemanrop ska ligga i CPU register rdi, andra argumentet ska ligga i register rsi och numret på det systemanrop man vill göra ska ligga i rax.

Viktigt att notera kring systemanrop och något som fundamental skiljer dem från "vanliga" funktionsanrop är att man inte behöver (man kan inte heller) specificera en minnesadress dit man vill hoppa. Systemanrop är en hård barriär mot OS-kärnan där effekten av att anrop systemanropet helt dikteras av OS-kärnan.

Ta nu ett program som anropar open(), detta är skillnaden mellan hur Cygwin, SFU/SUA resp. vad man nu lagt in i Win10

• med Cygwin har man POSIX kompatibilitet på källkodsnivå, d.v.s. anropet open() implementeras i cygwin1.dll som i sin tur kommer paketera om argumenten och anropa Win32 funktionen OpenFile(). OpenFile() är i sin tur implementerad Kernel32.dll och där kommer ett systemanrop till NT-kärnan ske (kan inte namnet/numret så där rakt av men är inte viktigt). Formatet på binären är samma som alla Windows-program, d.v.s. COFF

• med SFU/SUA implementera detta lager själv symbolen open(), så vi har fortfarande endast kompatibilitet på källkodsnivå då binären gör att anrop till adressen där open() ligger. I detta fall kommer man direkt göra ett systemanrop till NT-kärnan från open() (eventuellt samma systemanrop som OpenFile() gör), så jämfört med Cygwin har man kapat ett steg. Binärer måste ha COFF format

• vad man nu gör i Win10 är att Windows-kärnan exporterar (alla?) systemanrop Linux har, vilket faktiskt inte är så många Linux har runt 300 systemanrop (Windows kärnan har tusentals systemanrop, så lite lurigare att göra det omvända...). Nu när open() anropas så hamnar man i glibc, glibc gör vad det alltid gör på x86_64 i detta läge och så länge som systemanrop nummer 2 gör det som förväntas kvittar det om kärnan är Linux, FreeBSD (som också har ett liknande stöd) eller Windows. I detta läge är det samma binär. Kompatibiliteten är nu på binärnivå, inte bara på källkodsnivå, d.v.s. man kör med ELF i stället för COFF.

Notera dock att detta är inte explicit något Microsoft sagt, men förutsatt att man inte ljuger/överförenklat något i sina presentationer är detta sättet man rimligen måste ha gjort det på.

Linux + QEMU har ett ganska coolt sätt att utnyttja detta med systemanrop. Är möjligt att bygga t.ex. 32-bit ARM binärer, sedan kör man igång dessa m.h.a. av QEMU på sin x86_64 maskin. Alla systemanrop fångas av QEMU och argumenten översätts till vad x86_64 förväntar sig, slutresultatet blir alltså att man kör 32-bit ARM binärer där alla anrop mot OSet hanteras av den existerande kärnan vilket leder till att prestanda blir helt OK och man får ett trevligt sätt att debugga applikationer som i slutändan kanske ska köras på någon rikligt simpel enhet.

Exakt, det handlar om att man verkligen kör Ubuntu user-space ovanpå Windows-kärnan. Det handlar inte om någon form av emulering eller liknande, i userland är all kod man kör i denna Ubuntu-avbild samma som den man kör i "vanliga" Ubuntu. Systemgränsen dras vid systemanrop och hela poängen med systemanrop är att skapa ett API mellan user-land och kernel som totalt dikteras av kärnan. Om systemanropen fungerar på samma sätt som med en Linux-kärnan finns det helt enkelt ingen skillnad för userland om kärnan råkar vara Linux eller Windows.

Kort och gott: man kör verkligen "riktiga" Ubuntu, apt-get install emacs installerar samma binärer direkt från Ubuntus vanliga x86_64 repo som man får till sin x86_64 Ubuntu installation.

Detta har stöts och blötts redan och är ett totalt icke-problem i detta fall. Vad man sagt är att systemanropen inte innefattar GPLs "derived work", d.v.s. saker som befinner sig på olika sidor om systemanropsbarriären är även separerade ur GPLs synvinkel. Man diskuterade detta en hel del kring Android då Android kör en Linux-kärnan som är GPLv2 medan man har ett specialdesignat userland där t.ex. libc (Bionic) har BSD-licens i Android medan det är LGPL (glibc) i typiska Linux-distron.

Google har med detta säkerställt att man inte bryter mot GPL i Android trots att man har proprietära delar i userland. I Win10 fallet har man en proprietär kärna och ett separat userland som uppfyller samma krav som "vanliga" Ubuntu.

Enda potentiella fallgropen är om Oracle lyckas vinna mot Google och själva API-definitionen kan anses vara skyddade. I det läget ligger Microsoft lite pyrt till då man implementerar Linux systemanrop. Men låt oss bedja att Oracle förlorar så det visslar om det i denna andra runda mellan GOOG och ORCL (handlar om att Google använder delar av Javas API i Android, rätten har redan fastslagit att Google inte snott något från Oracles JRE). Vinner Oracle detta kan vi som jobbar i branschen packa ihop och fundera på vad man ska göra härnäst...