Portably and efficiently implementing it in the kernel still requires a fixed point (integer operations) approximation. I'm sure the authors were using "necessa

Portably and efficiently implementing it in the kernel still requires a fixed point (integer operations) approximation. I'm sure the authors were using "necessary" in the sense of practicality, not in the sense of "impossible otherwise". If they used fp in the kernel, it wouldn't work on some hardware that is supported on Linux (requiring conditional compilation). If they emulated floating point, even single precision IEEE-754 multiplication would require 24bit x 24bit -> 48bit multiplies, and supporting denormals would require 48-bit bit scans and variable-width shifts. It all gets very slow in a hurry (oxymoron intended) on hardware with 32-bit integer hardware and no hw fp. They could choose to emulate some non-IEEE-754 fp format that's slightly more efficient... but that sounds needlessly complex for little to no benefit. So, their remaining option is to use fixed point operations. It's all noisy approximations with TCP in the real world anyway, so I doubt that there's a measurable difference in throughput when using the fixed-point approximation models vs. using the floating point approximation models. As an added bonus, they get consistent results across architectures. Though I think that all supported hardware that has hw fp uses that hardware in a mode that at least close to IEEE-754 compliance, so differences would be tiny. Some hardware supports both IBM format floating point and IEEE-754. As far as I know, the Linux VAX port was never completed. IBM and VAX are the main non-IEEE-754 floating point formats encountered outside of GPUs/TPUs. Edit: or maybe they meant "necessary" in the "Linus will ban me for life if I submit such a silly patch" sense.