When you say "base 10", is that "10"-er written in big endian or small endian?
It's as if there's a convention of sorts to how we write numbers (regardless of base).
If you don't state endianness in your exercise, one should assume the convention is followed.
That makes no sense. The value of two bytes as a single number is strictly dependent on endianness, and there's no "convention" that can be assumed.
You're saying you believe every Linux driver actually is a glorified while loop?
I guess it makes sense you're having trouble hiring qualified candidates.
He's arguing most drivers are mostly event driven --- which is true, trivially.
Nowhere did he argue that. What he actually argued--poorly and offensively--is that it's "pretty obvious" that bronson has no experience writing Linux hardware drivers.
That's remarkable, since his comment says nothing about events.
Still, it sounds like you're saying that Linux drivers are more than glorified do loops spinning on IRQs, right? If so, then I guess we agree.
My anecdotal experience interviewing big tech engineers that used Rust reflects GP's hunch about this astonishing experience gap. Just this year, 4/4 candidates I interviewed couldn't give me the correct answer for what two bytes in base 2 represented in base 10. Not a single candidate asked me about the endianness of the system.
Now that Rust in the kernel doesn't have an "experimental" escape hatch, these motte-and-bailey arguments aren't going to work. Ultimately, I think this is a good thing for Rust in the kernel. Once all of the idiots and buffoons have been sufficiently derided and ousted from public discourse (deservedly so), we can finally begin having serious and productive technical discussions about how to make C and Rust interoperate in the kernel.