| 64 | | TBD |
| | 64 | (informal notes on some of the discussions that benefit from writing down) |
| | 65 | |
| | 66 | * MSI (samuli, simon, ...) |
| | 67 | * discussed - next steps? |
| | 68 | |
| | 69 | * route.c / tun.c rehaul (ordex, dazo, cron2, jjk) |
| | 70 | * Linux support for ifconfig/route is dropped |
| | 71 | * we keep iproute2 support (because jjk brought up special cases where you really want to call out to external programs that can be wrapped to "do local thins", and --up scripts are just much more effort) |
| | 72 | * we add direct netlink support |
| | 73 | * netlink support needs to come along with strong unit tests that verifies all setter/getter operations using explicit "ip ..." calls to verify that our abstraction layer is really doing what it's meant to (cron2 worried about binary representations being error-prone) |
| | 74 | * the netlink library needs to clearly print what it does to the log ("what it thinks it does", and the unit test needs to ensure that this is actually true) |
| | 75 | * we split route.c to route.c and route-platform.c, but we do not want route-{linux,freebsd,netbsd,solaris,..}.c as that would be mostly copy-paste code duplication of mostly identical code with "one line different" (the route call) |
| | 76 | * we look into splitting tun.c into tun-unix.c and tun-win32.c, but not tun-{linux,freebsd,netbsd,solaris,...].c, for the same reasons |
| | 77 | * tun.c needs to see all those nearly-identical tun_read()/tun_write() functions merged into one place, and then we see what else is copy-paste code reuse |
| | 78 | |
| | 79 | * vagrant (dazo, mattock, cron2) |
| | 80 | * ...? |
