/proc/version and uname -a information are currently not that useful.

[bogen]

WSL /proc/version compiler and date output are not all that useful.

• The contents of /proc/version are misleading.
• Expected results: meaningful compiler and build date
  • Actual compiler used. If the Linux kernel someone was using was built with clang, the clang information would be indicated rather than gcc.
  • Build date sould be when kernel was built, for WSL when the syscall layer was built.
• My WSL environment:
  • Edition: Windows 10 Enterprise
  • Version: 1607
  • OS Build: 14393.0
• Actual results (with terminal output if applicable)

$ cat /proc/version 
Linux version 3.4.0-Microsoft (Microsoft@Microsoft.com) (gcc version 4.7 (GCC) ) #1 SMP PREEMPT Wed Dec 31 14:42:53 PST 2014

• Based on the output above one would be led to believe that WSL has not been updated for over a year and a half which is not true. It also indicates that WSL is built with GCC. Is it really?
• Does the 3.4.0 in the above output indicate the syscalls supported? In other words, no syscalls introduced after Linux 3.4.0. I do understand that WSL does not support all Linux syscalls yet.
• uname -a output is even worse:

$ uname -a
Linux MYHOSTNAME 3.4.0+ #1 PREEMPT Thu Aug 1 17:06:05 CST 2013 x86_64 x86_64 x86_64 GNU/Linux

• The above output would indicate WSL has not been updated in over 3 years. The "3.4.0+" is also a mismatch from "3.4.0-Microsoft". On all GNU/Linux systems I've used, the date for in the "cat /proc/version" and "uname -a" outputs are the same. Also, one says "Will this be Open Source? #1 SMP PREEMPT" and the other says "Will this be Open Source? #1 PREEMPT" which is another indicator that "uname -a" and /proc/version are not getting their information from the same place.
• When one does "cat /proc/version" and "uname -a" they expect something valid, just like when someone goes to Windows Settings About, they expect valid information that reflects the platform they are running on.
• For reference, here are the outputs from an ubuntu xenial system:

$ uname -a
Linux MY-HOST-NAME 4.4.0-31-generic #50-Ubuntu SMP Wed Jul 13 00:07:12 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux
$ cat /proc/version
Linux version 4.4.0-31-generic (buildd@lgw01-16) (gcc version 5.3.1 20160413 (Ubuntu 5.3.1-14ubuntu2.1) ) #50-Ubuntu SMP Wed Jul 13 00:07:12 UTC 2016

• When the WSL team wants to know what WSL build someone is using, end users should be able to use the output of "uname -a" or "cat /proc/version" to provide that information, as one would expect to do from any GNU/Linux platform.

[fpqc]

@bogen I think that kernel version is the version that the Ubuntu-trusty binaries are expecting. It's probably the version of the usermode ABI that MS is targeting right now. For example, technically WSL should not identify itself as "Linux" at all, since "Linux" is actually the name of the kernel. I understand why it might frustrate you not to have everything nice and accurate in procfs, but the team has other priorities and will only clean up various bits of cruft as they get to it. For instance, the RS2 builds have finally removed the Android Binder interfaces left over from project Astoria (which actually forms much of the basis of WSL), and you may have noticed that when the very first build of WSL was demoed at //build 2016/, the mysterious /dev/lxss was called /dev/adss (adss = android subsystem). I bet that the Linux Kernel number and build-date have been sitting there untouched since they first dropped them in while they were working on Astoria (the timeline fits) and just haven't gotten around to changing them.

The point is that right now it's not important. These are basically things that even on Linux are hardcoded in the Kernel. In WSL, I bet that they are just hardcoded in the init process (because WSL doesn't use udev, it looks like devfs and procfs are set up pretty much hardcoded by init, which I hope will change in the future).

[bogen]

@fpqc on Linux they are not hardcoded, they are generated with each kernel build. If the Linux kernel is updated, it is updated.

Agreed, WSL should technically not identify as Linux. I agree that right now this is less important than other issues.

But at the same time, they not superflous items. In windows or any other software when I do an about, it should be relevant up to date information. Doing a uname -a or a cat /proc/version is the equivalent of that. I've not seen other Microsoft applications containing stale about information when they have obviously changed (in regard to version information, build numbers, etc). How is WSL any different in that regard?

[fpqc]

@bogen On a real installation of Linux, you have the kernel launch an init process (like sysvinit or upstart or systemd), which then calls something like the legacy Linux HAL or the modern udev, which construct and provide the dev and proc filesystems based on information obtained from the Kernel (also in the past, HAL and udev did firmware loading for some reason, but the udev developers won out in a heated and impolite argument with Linus to have this stuff moved directly into the Kernel).

Since WSL is not running on real hardware (all of its device interfaces are not provided by bare-metal firmware but by already-abstracted Windows objects, it does not actually need to support a general solution like udev (and likely also because the team didn't want to wait to show off the project just to get udev actually working as part of an already-obsolete real-world init solution (remember, upstart is already deprecated anyway, so it is pointless to target)). So since MS decided to hack together an init for these beta releases (thus making it possible to start up WSL without them implementing the probably specialized udev syscalls), it was probably inevitable that they might be providing some of the things like procfs or devfs in nonstandard ways (for example, hardcoding the kernel string, various networking-related things (which is why ifconfig doesn't work at all), the user's login shells (/bin/bash), the fstab (totally ignored so that WSL mountpoints are practically hardcoded, and iirc mounts like /mnt/c do not actually even correspond to block devices at all in /dev), ttys, ptys, etc).

We haven't heard yet if MS is planning to support systemd, but if they do, they will likely have to provide their "device" initializations directly in lxss/lxcore in a way that udev can understand rather than doing so much of the init based on Windows-provided information of unclear provenance (I am sure @ionescu007 has more than a good idea of how init currently works, and he might be more forthcoming on details than the WSL team (because afaict it is a pretty dirty hack), at least if you can catch him at a Con).

Some of what I am saying may be wrong, but it is largely obtained by comparing how an actual Linux init works (systemd/sysvinit and udev), and what we know is missing in WSL (in this case udev).