Enable udev by default (it can be useful when using usbip) #225
Conversation
We can support usbip with the Microsoft Store version of WSL (I think that's the one that introduced the change, also turned on WSLg) Related is nix-community#175 (comment) which is where it got disabled, because it wasn't necessary rather than because it broke things
|
The rationale it's disabled by default is that it's not typically needed, so it shouldn't be installed. Is there anything else needed for usbip or does it just work out of the box if udev is enabled? |
|
It works out of the box* even without this, just udev rules don't work without this of course. *The corporate firewall has all public network ports closed without being able to bypass (presumably excluding system DHCP probably) so I cannot use anything with WSL that needs to listen on the Windows host and connect to it from WSL. So I have a wireguard tunnel between the two, which I can change the connection profile to be private (I couldn't for the WSL/Hyper-V switch). This just means I cannot use the helper usbip and have to instead do where 10.0.0.1 is the win host side of the wireguard tunnel. Of course I don't blame IT, I think closing public network ports sounds reasonable, but not being able to change the network connection profile for Hyper-V switches is annoying |
|
You can just turn udev on for your config. |
|
Sure, and I already do this, but the question is why not have it enabled as the default? Maybe it's just because my colleagues also work with embedded software, but everyone else I know uses WSL with usbip (and udev rules for openocd). It doesn't make that much of a difference: ❯ git show
commit 9a806060b71a021ec5d71c2fabdb250893be1082
Author: Kovacsics Robert <[email protected]>
Date: Thu Mar 9 00:15:35 2023 +0000
Add udev config
diff --git a/flake.nix b/flake.nix
index 7ec08e9..42077e0 100644
--- a/flake.nix
+++ b/flake.nix
@@ -39,6 +39,14 @@
];
};
+ nixosConfigurations.mysystem-udev = nixpkgs.lib.nixosSystem {
+ system = "x86_64-linux";
+ modules = [
+ ./configuration.nix
+ { services.udev.enable = true; }
+ ];
+ };
+
} //
flake-utils.lib.eachSystem
[ "x86_64-linux" "aarch64-linux" ]
❯ nix build '.#nixosConfigurations.mysystem.config.system.build.installer' -o mysystem-installer
❯ nix build '.#nixosConfigurations.mysystem-udev.config.system.build.installer' -o mysystem-installer-udev
❯ ls mysystem-installer*/tarball/*.tar.gz
╭───┬────────────────────────────────────────────────────────────┬──────┬──────────┬──────────────╮
│ # │ name │ type │ size │ modified │
├───┼────────────────────────────────────────────────────────────┼──────┼──────────┼──────────────┤
│ 0 │ mysystem-installer/tarball/nixos-wsl-installer.tar.gz │ file │ 395.0 MB │ 53 years ago │
│ 1 │ mysystem-installer-udev/tarball/nixos-wsl-installer.tar.gz │ file │ 396.8 MB │ 53 years ago │
╰───┴────────────────────────────────────────────────────────────┴──────┴──────────┴──────────────╯Though perha |
|
Its probably just your bubble :) but the 1.8M we probably have to spare. What do you say @nzbr ? |
|
I don't think the size of the tarball is an issue at all. I'm more interested in how much having udev affects startup times. It's probably not much, but if it is something like 5 seconds or more, I'd rather leave it as opt-in and put the relevant flag in configuration.nix with a comment instead |
|
Good news on that front (sorry about the ugly sed expression, it just highlights the lines matching Couple runs of `wsl.exe --shutdown`, then using `systemd-analyze` to check the startup time❯ systemd-analyze blame | sed 's/.*udev.*/+&/; t; s/.*/ &/'
1.280s wsl_resolv.service
1.086s tailscaled.service
605ms home-manager-rmk.service
521ms [email protected]
515ms dbus.service
492ms systemd-logind.service
242ms dev-sdc.device
212ms systemd-resolved.service
184ms systemd-tmpfiles-clean.service
147ms WSL2-VPN.service
+ 69ms systemd-udev-trigger.service
49ms systemd-journal-flush.service
44ms clamav-freshclam.service
44ms systemd-journald.service
41ms nscd.service
+ 32ms systemd-udevd.service
23ms systemd-tmpfiles-setup-dev.service
21ms dev-mqueue.mount
21ms clamav-daemon.service
20ms sys-kernel-debug.mount
19ms alsa-store.service
18ms [email protected]
18ms dev-hugepages.mount
17ms [email protected]
15ms systemd-modules-load.service
14ms systemd-tmpfiles-setup.service
13ms logrotate-checkconf.service
13ms [email protected]
12ms sshd.service
10ms systemd-binfmt.service
9ms systemd-update-utmp.service
6ms systemd-sysctl.service
6ms sys-fs-fuse-connections.mount
5ms systemd-user-sessions.service
5ms atop-rotate.service
5ms [email protected]
4ms modprobe@efi_pstore.service 1.669s wsl_resolv.service
843ms home-manager-rmk.service
215ms tailscaled.service
195ms [email protected]
187ms dev-sdc.device
138ms systemd-resolved.service
130ms dbus.service
111ms systemd-logind.service
81ms WSL2-VPN.service
76ms systemd-tmpfiles-setup.service
48ms systemd-journald.service
+ 47ms systemd-udev-trigger.service
+ 44ms systemd-udevd.service
35ms systemd-journal-flush.service
33ms dev-hugepages.mount
32ms dev-mqueue.mount
31ms sys-kernel-debug.mount
30ms nscd.service
30ms [email protected]
29ms systemd-sysctl.service
28ms [email protected]
28ms modprobe@efi_pstore.service
27ms [email protected]
16ms systemd-tmpfiles-setup-dev.service
15ms clamav-daemon.service
14ms alsa-store.service
11ms [email protected]
11ms systemd-user-sessions.service
9ms logrotate-checkconf.service
8ms systemd-update-utmp.service
8ms systemd-binfmt.service
7ms sshd.service
2ms sys-fs-fuse-connections.mountI'm using a decent laptop (Lenovo P15s) |
|
That's better than I expected! I'm gonna merge it then Off-Topic question: What ls replacement are you using? |
nzbr
changed the title
|
@nzbr It's the built-in one to https://www.nushell.sh/ actually, it's nushell that's clever and supports structured data :) It is definitely experimental though, I've got plenty of things I plan on contributing to it |
|
Unless it has nerdfont symbol support, I don't think I could use it :(
Jokes aside: those new shells are not fully grown up yet and often feel more like toys. Also that nothing continues to work is always a big bummer. |
|
Definitely not fully grown up yet :) I'm hoping the annoyances will make me contribute to it, but I'm sure you know how it is with spare time and attention span :) And that's cool, I'll have to look into that |
|
Going to revert this because it draws in firmware which is 300MB big and cannot easily be disabled. |
We can support usbip with the Microsoft Store version of WSL (I think that's the one that introduced the change, also turned on WSLg)
Related is #175 (comment) which is where it got disabled, because it wasn't necessary rather than because it broke things
See #111 for NixOS-WSL usbip discussion