path: root/tools/testing/selftests/wireguard/qemu/init.c
diff options
authorJason A. Donenfeld <Jason@zx2c4.com>2020-05-31 23:58:24 -0600
committerJason A. Donenfeld <Jason@zx2c4.com>2020-06-01 01:00:26 -0600
commit079d4aef3cd8dbf1c826e6cb683dfbdda2a2f964 (patch)
tree85f19dbb4e4a808228eba29531c51a79a972dba5 /tools/testing/selftests/wireguard/qemu/init.c
parentcrypto: poly1305 - add library selftests (diff)
wireguard: reformat to 100 column lines
While this sort of change is typically viewed as "trivial", "cosmetic", or even "bikesheddy", I think there's a very serious argument to be made about the readability and comprehensibility of the code as a result. One of the principle motivations for WireGuard is that the code is readable and, generally, enjoyable to read, so that people do actually spend time understanding it and helping to find bugs. Changing the original codebase to 80 columns was a painful exercise, and resulted in something much less satisfactory than desired. It wasn't really worth debating -- conventions are conventions, after all -- but with the recent Linux style guideline being changed from 80 to 100, we can finally revisit this. The end result makes a considerable difference. Even when developing on this code base prior, I tended to work in ~100 line columns, sometimes reformatting a function for the purposes of development, before packaging it back up for the mailing list. With this change, development and maintenance also becomes a more enjoyable task. Generally speaking, I did not write WireGuard with butchered variable names, preferring things that would be immediately memorable and recognizable for readers. For example, I prefer to name the ephemeral private key "ephemeral_private" instead of "ep" or "eph_priv", so that there's no guess work or additional cognitive strain when auditing. It seems like many other parts of the kernel have made similar choices. For example, "hlist_for_each_entry_rcu_bh" is a very clearly named function, that tells me exactly what it's going to do, without needing to guess or look things up in documentation. But it's also 27 characters. Previously this would cause all sorts of gnarly wrapping; now it reads naturally. To be clear, this isn't at all a reversion to the original v1 submission of WireGuard, which had wild and out of control column widths. Rather, this is a thorough reworking based on the readability afforded to us now by the 100 column guideline. This also isn't some kind of machine-made automated conversion. All of this has been reworked by hand, hours of work, with real attention to detail, given 100 column constraints. My hope in paying attention to readability like this is that it will produce a more maintainable codebase, as well as being more attractive to audit and understand fully. Logistically, it also happens to be a good time in the development cycle for making these kinds of changes. Since, as mentioned earlier, I did do this by hand, I've made sure that the actual resulting algorithms haven't changed at all by accident. The only actual change is that device.o winds up slightly different, due to the call to `ASSERT_RTNL` in `wg_netdevice_notification`. That macro expands to something with __LINE__ in it, which then changes the input argument to the printk. Beyond this, the object files are byte-for-byte identical. Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Diffstat (limited to 'tools/testing/selftests/wireguard/qemu/init.c')
0 files changed, 0 insertions, 0 deletions