Vlákno názorů k článku
Windows Subsystem for Linux už nebude beta
od lazywriter - "když ze své podstaty nikdy dokonalý nebude" -...
-
Autor zprávičky zřejmě nechápe fundamentální rozdíl mezi WSL a Wine. Wine reimplementuje část Win32 API. WSL implementuje jen linuxové syscally, kterých je pár set.
MS zveřejňuje seznam implementovaných syscallů. Nejsou implementované všechny:
- Některé se v principu implementovat nebudou, například create_module, init_module, delete_module.
- Některé nejsou implementované ani na recentních verzích linuxového kernelu, například afs_syscall, break, fattach, fdetach, ftime, getmsg, getpmsg, gtty, isastream, lock, madvise1, mpx, prof, profil, putmsg, putpmsg, security, stty, tuxcall, ulimit, vserver.
- Některé Linux na x86/64 vůbec nemá, například PCICONFIG_WRITE.
- Další MS implementovat asi nebude chtít, například SWAPON, SWAPOFF, CLOCK_SETTIME, CLOCK_ADJTIME.
- Nějaké by se v principu implementovat daly, například FANOTIFY_INIT, FANOTIFY_MARK, IOPRIO_SET (ten ovšem nemá podporu ani v řadě dister). -
Filip JirsákStříbrný podporovatelBash pod GTK? Vždycky jsem si myslel, že bash je konzolový program…
-
NULL (neregistrovaný)
/bin/bash je skutečně konzolový program. Program Bash na Win10 je to samé co na lin. desktopu konzolové emulátory, které běží (alespoň v distru které používám) pod GTK. No a o tom windowsovém byla řeč. Uznávám, mohl jsem to napsat přesněji, měl jsem za to že je to úplně jasná věc jako slunce nad hlavou . . .
-
Filip JirsákStříbrný podporovatel
Windowsový program pod Windows 10 ale zase nemá nic společného s Windows Subsystem for Linux. Windows Subsystem for Linuxu slouží ke spouště Linuxových konzolových programů, ne ke spouštění Windows programů.
-
Filip JirsákStříbrný podporovatel
Ten váš „Bash“ je jenom Windowsová konzole, ve které je spuštěný linuxový bash.
-
NULL (neregistrovaný)
Aha, takže abys mohl prudit, musíme přijmout že
windowsácká (řeč byla o WSL) "svérázné implementace např. Bashe ... " (hint: windows + velké B asi nebude /bin/bash)
znamená
"nějaká jiná implementace bashe"- což už ale tvrdíš ty, aby ses měl čím ohánět. Tobě už asi z těch neustálých pokusů někoho poučovat úplně přeskočilo ...
"Takže třeba ten Bash chceš říct je ten samý jako běží pod GTK"
Ano, zde jsem uznal že formulace nebyla nejšťastněší protože
"Takže třeba ten (windowsí program) Bash (tedy emulátor konzole) chceš říct je ten samý (emulátor konzole/konzolí) jako běží pod GTK"?
-
Filip JirsákStříbrný podporovatel
PS: Stejně je zajímavé, že v postatě každý s kým "diskutuješ", musí dříve či později prokazovat co řekl a neřekl oproti tvé interpretaci . . .
Prokazujte, prokazujte. Mám k tomu několik dotazů:windowsácká (řeč byla o WSL) "svérázné implementace např. Bashe ... " (hint: windows + velké B asi nebude /bin/bash)
znamená
"nějaká jiná implementace bashe"
Aha, takže podle vás „svéráznost“ té implementace „Bashe“ znamená, že je to úplně stejný bash, jako /bin/bash? Nebo jak to tedy podle vás je? Je „Windows Bash“ (ať už je to cokoli) je ta samá implementace bashe, jaká je třeba v Ubuntu, nebo je to jiná implementace?"Takže třeba ten (windowsí program) Bash (tedy emulátor konzole) chceš říct je ten samý (emulátor konzole/konzolí) jako běží pod GTK"?
Ano, uznal jste, že formulace nebyla nejšťastnější, a napravil jste ji opět nešťastnou formulací. To, co vy nazýváte „program Bash“ je ve skutečnosti normální linuxový bash (tedy shell, žádný emulátor konzole) spuštěný ve Windowsovském emulátoru konzole. GTK (ve skutečnosti už celkem dlouho GTK+) je „GIMP Toolkit“, knihovny pro tvorbu aplikací s GUI. Tedy neběhá nic „pod GTK“, jsou aplikace naprogramované „pomocí GTK+“. -
NULL (neregistrovaný)
Bash na windows je Bash na windows. O bash nebo /bin/bash tady mele jenom Jirsák. Tak nevím o čem jako špekuluješ. Vim, pokud vím, přímo "vim" je taky verze pro windows. V tom se možná pletu, každopádně se nechová jako na lin., na widlích padá jak zralé hrušky . . .
S SSH nevím co jestli mi to bude fungovat, ale odhadem na Debianu mi za 3 roky práce nespadlo SSH tolikrát co na WSL za několik měsíců. Takže ano, nefunguje. Jestli budeš slovíčkařit co že to tam kde přesně přemostili nebo podšouply pod syscally, klidně. posluž si . . . -
Filip JirsákStříbrný podporovatel
Bash na windows je Bash na windows. O bash nebo /bin/bash tady mele jenom Jirsák.
Já když spustím „Bash on Ubuntu on Windows“, spustí se mi ve Windows pod procesem LxssManager, pod ním je spuštěný proces init a pod ním proces bash. O procesech
initabashnení schopen Process Explorer vypsat nic o image file – ani cestu k souboru, ani příkazový řádek, ani aktuální adresář. Mimochodem, kromě 4 procesů pod Windows PID = 0 (System) jsou to jediné dva procesy v systému, jejichž název nekončí na.exe.Když se na to podívám z linuxové strany, vidím v emulátoru terminálu ve Windows tohle:
filip@PC:~$echo $$ 2 filip@PC:~$ps ax PID TTY STAT TIME COMMAND 1 ? Ss 0:00 /init 2 ? Ss 0:00 /bin/bash 14 ? R 0:00 ps ax filip@PC:~$Já tu melo o „Bash on Ubuntu on Windows“ na svém počítači. O čem tu melete vy?
-
Filip JirsákStříbrný podporovatel
Pardon, popsal jsem vám ten linuxový shell, zapomněl jsem na tu druhou polovinu, a tou je windowsovský emulátor terminálu. Tedy v procesech už normálně pod explorer.exe je spuštěný
bash.exe(to je ten váš Bash s velkým „B“), jinak také „Microsoft Bash Launcher“. A pod ním běží – překvapení –connhost.exe, nebo-li Console Window Host. Takže už máme shell (/bin/bash, linuxová binárka, standardní shell z Ubuntu), a k tomu emulátor konzoleconnhost(což je zase standardní binárka Windows), který používají i ostatní konzolové programy pro Windows (třebacmd– příkazový řádek, nebo PowerShell).bash.exeje jenom spouštěč, který spustí/bin/inita/bin/bashpod WSL a propojí vstup a výstup toho/bin/bashnaconnhost. -
higgsuv boson (neregistrovaný)
Simple.
$ ldd /bin/bash
linux-vdso.so.1 => (0x00007ffd30f9c000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f05b6703000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f05b64ff000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f05b6134000)
/lib64/ld-linux-x86-64.so.2 (0x00005559bc248000) -
> BTW jaký je rozdíl mezi bypassem Win32 API a bypassem hromady syscallů?
WIndows API je implementováno pomocí syscallů. Pokud aplikace chce, může Windows API obejít, kdy se jí zachce (což znamená, že do něj např. přímo nemůžete implementovat např. věci týkající se bezpečnosti, protože u nich chcete, aby vám je nikdo neobešel). Kód aplikace ale syscally obejít nemůže – pokud neexistuje systémové volání pro daný scénář, má prostě smůlu.
Takže tato reimplementace syscallů by měla (teoreticky) zachytit i aplikace, které syscally přímo používají (včetně vlastní instrukce přechodu do jádra (sysenter, syscall, int n). V případě reimplementace Win API se to z principu nemůže podařit.
-
asdfhsdjh (neregistrovaný)
ooo mocny guru, v cygwine nie je mozny ssh multiplexing a nativny fork kvoli odlisnemu pristupu k danej problematike. Ako to bude riesene vo WSL? poradi si ssh client s parametrami controlmaster a controlpath? a ked budem masivne paralelizovat "linuxove" procesy, tak mi to spomali beh systemu na neakceptovatelne urovne?
Sucasne chovanie nedavam za chybu ani windowsu, ani cigwinu. Je to bud neriesitelny problem ako s ssh multiplexingom , alebo forkovanie je riesitelne cez hacky. Len by ma zaujimalo ci sa na to prekladanie syscallov pozreli v MS poriadne a naimplementovali to funkcne.
-
> ooo mocny guru, v cygwine nie je mozny ssh multiplexing a nativny fork kvoli odlisnemu pristupu k danej problematike. Ako to bude riesene vo WSL?
Fork byl (a možná ještě je) ve Windows implementován v rámci syscallu NtCreateProcess. Zkoumal jsem to ale tak před deseti lety, takže nevím, zda tato nedokumentovaná funkcionalita přežila do dalších verzích Windows (kde se spíš používá volání NtCreateUserProcess). Ve strších Windows musel být nějak řešen, neboť disponovaly také subsystémem POSIX.
-
Adam KaliszStříbrný podporovatelJe to popsané tady: https://blogs.msdn.microsoft.com/wsl/2016/04/22/windows-subsystem-for-linux-overview/
"System Calls
WSL executes unmodified Linux ELF64 binaries by virtualizing a Linux kernel interface on top of the Windows NT kernel. One of the kernel interfaces that it exposes are system calls (syscalls). A syscall is a service provided by the kernel that can be called from user mode. Both the Linux kernel and Windows NT kernel expose several hundred syscalls to user mode, but they have different semantics and are generally not directly compatible. For example, the Linux kernel includes things like fork, open, and kill while the Windows NT kernel has the comparable NtCreateProcess, NtOpenFile, and NtTerminateProcess.
The Windows Subsystem for Linux includes kernel mode drivers (lxss.sys and lxcore.sys) that are responsible for handling Linux system call requests in coordination with the Windows NT kernel. The drivers do not contain code from the Linux kernel but are instead a clean room implementation of Linux-compatible kernel interfaces. On native Linux, when a syscall is made from a user mode executable it is handled by the Linux kernel. On WSL, when a syscall is made from the same executable the Windows NT kernel forwards the request to lxcore.sys. Where possible, lxcore.sys translates the Linux syscall to the equivalent Windows NT call which in turn does the heavy lifting. Where there is no reasonable mapping the Windows kernel mode driver must service the request directly.
As an example, the Linux fork() syscall has no direct equivalent call documented for Windows. When a fork system call is made to the Windows Subsystem for Linux, lxcore.sys does some of the initial work to prepare for copying the process. It then calls internal Windows NT kernel APIs to create the process with the correct semantics, and completes copying additional data for the new process."
