A student’s mind is like a blank slate. What you teach them is what they write in that slate and this is why one should not misguide them by teaching, it is better to admit that you do not know something rather than leading them down the wrong path. – A Mathematics Professor
Failure is not something that is new to me, and to me failure has been a great teacher in ways of how NOT to do things. But that is not what upsets me in this specific case, let me elaborate.
The NetBSD board finally got back to me regarding the project and it was quite clear that I did not jackshit about what I wrote up and it is not too far from the truth.
Also there are a lot of N/F and ? entries in your API matching table, and from the proposal it is not clear how fammiliar you two are with the internals of the NetBSD networking stack.
I should have followed my gut instinct here and should have looked into easier projects to pick up to gain experience instead of embarking on a fool’s quest on doing something like porting the entire wireguard protocol into NetBSD. Not because the task is impossible but the sheer lack of my experience in writing kernel code.
Just FTR I’m not actively part of the proposal. I’m purely involved in an advisory capacity.
This along with the rather hand-wavy support from cherry@ along with his obsession about not using “kernel module” to write up the wireguard interface was not helping me. Even though I managed to export a kernel module to userland[1] for writing up ATF tests, this was apparently not good enough for him to point me in the right direction for wireguard.
Even at advisory capacity, the incompetence was beyond comprehension. And by this I do not mean I intend to be carried[2] by cherry@ in this project. A simple technical review of the proposal by cherry@ did not find the obvious blunders in the technical details I put forward in the proposal. An advisor even in the least of the capability should be able to point out what seems to be obviously wrong and in worst case admiting that they are not qualified to advice on the topic instead of giving me tips and tricks on how to improve my english grammar in the proposal.
I think there is a lot of communication gap in what I intend to do and tasks assigned by cherry@. More over his lack of interest in doing systems programming is showing, which is an understandable when one has worked on these things as long as someone like cherry@ has especially when it is driven by a need for survival than a pursuit of passion.
After further discussion with cherry@, we came up with a statement…
Please give us a bit more time - until the end of June, to start on the research for this. At this point I will personally have finished up on the x86 stuff as well and will have more headspace. Sorry for going quiet, and no, we hadn’t dropped the ball.
Personally I think we have lost the edge in trying to port WireGuard to BSD, despite the ground work I laid out towards the end of 2017. And it looks like it is only going to get worse before someone else picks up the slack and finishes this.
In conclusion I see this as my failure to grasp the underlying complexity of systems programming. A field dedicated to create abstractions between hardware and software so that idiots like me can type things like this into a file without ever knowing the intricate details and behind the scenes of how a file is being opened or maintained in memory, not to mention the plethora of things happening from capturing my key strokes, displaying them on screen and saving them to a disk.
I am not driven to poke into operating systems as means of survival, instead I am passionate about computers in general. As a person who likes to poke around and get to know how things work, systems programming is the way to go, it is not an easy path from what I hear, but later in life when I look back this may have been a struggle that is worth fighting for.
References
- https://github.com/fraggerfox/rperm-netbsd
- https://www.urbandictionary.com/define.php?term=Carried