On 12/31/12 8:30 PM, Paul D. Fernhout wrote:
So, I guess another meta-level bug in the Linux Kernel is that it is
written in C, which does not support certain complexity management
features, and there is no clear upgrade path from that because C++ has
always had serious linking problems.
But the ABIs aren't specified in terms of language interfaces, they are
architecture-specific. POSIX kernel interfaces don't need C++ link
level compatibility, or even extern "C" compatibility interfaces.
Similarly on the device side, that's packing command blocks and such,
byte by byte. Until a few years ago, GCC was the only compiler ever
used (or able) to compile the Linux kernel. It is a feature that it all
can be compiled with one open source toolchain. Every aspect can be
improved.
From that thread I read that those in the Linus camp are fine with
abstraction, but it has to be their abstraction on their terms. An
later in the thread, Theodore T'so gave an example of opacity in the
programming model:
a = b + "/share/" + c + serial_num;
Arguing "where you can have absolutely no idea how many memory
allocations are
done, due to type coercions, overloaded operators"
Well, I'd say just write the code in concise notation. If there are
memory allocations they'll show up in valgrind runs, for example. Then
disassemble that function and understand what the memory allocations
actually are. If there is a better way to do it, then either change
abstractions, or improve the compiler to do it more efficiently. Yes,
there can be an investment in a lot of stuff. But just defining any
programming model with a non-obvious performance model as a bad
programming model is shortsighted advice, especially for developers
outside of the world of operating systems. That something is
non-obvious is not necessarily a bad thing. It just means a bit more
depth-first investigation. At least one can _learn_ something from the
diversion.
Marcus
_______________________________________________
fonc mailing list
fonc@vpri.org
http://vpri.org/mailman/listinfo/fonc
