I feel you are focusing on the literal aspect of what I wrote and ignoring the broader implications. The tradeoff here between "student OS kernel principles" an

I feel you are focusing on the literal aspect of what I wrote and ignoring the broader implications. The tradeoff here between "student OS kernel principles" and "grind through a USB driver implementation" will recur as you try to add drivers and hardware to run meaningful-to-users workloads. So you wind up with a research operating system that has finger-painting graphics, can't talk to modern SSDs or networks cards... or you somehow conjure up the resources to build an enormous number of drivers. If you "hack Linux or a bsd" - or even more timidly - use ebpf - the constraints of what you build are going to result in you basically building "more UNIX stuff". This isn't bad research, but the sheer mass of constraints you're taking on if you accept all the design tradeoffs of Linux/bsd/eBPF/whatever means you're certainly not doing the sort of OS research that the original author talked about.