| |||||||||||||
|
| |||||||||||||
Writing kernel modules in HaskellWriting kernel modules in HaskellPosted Sep 14, 2009 0:14 UTC (Mon) by cesarb (subscriber, #6266)In reply to: Writing kernel modules in Haskell by bjacob Parent article: Writing kernel modules in Haskell
Just a note in your second point: yes, C++ can hide memory allocation behind your back. Even a seemingly simple statement like "a = b + c;" can allocate memory in C++, while in C the only way that statement will allocate memory is if the compiler has to spill registers, and even then the allocation will be small and on the stack. In C++, the same "a = b + c;" statement could read from the disk, send a network packet, and draw a smiley face on your screen.
Of course, that can only happen if you create a class elsewhere which does memory allocation (and the other evil things) on "operator+" (and if you have not decided to forbid operators in your classes). But I think Linus's point is that, once you allow the language, people will want to use the features of the language, and before long you lose the ability to tell at a glance the costs and side effects of even simple operations like "a = b" (which in C can only mean the equivalent of a simple "MOV").
In fact, if you look at it this way, the fact that C is less expressive than C++ can be a feature. Having to write things like "obj->ops->fn(obj, foo)" instead of "obj->fn(foo)" makes explicit the extra costs (in this case, an additional memory read for the vtable and the extra "hidden" parameter).
(Log in to post comments)
Writing kernel modules in Haskell Posted Sep 14, 2009 0:32 UTC (Mon) by bjacob (subscriber, #58566) [Link]
All these arguments are indeed defendable --- but again, they are arguments against using C++ throughout the kernel, and hardly constitute an argument against using C++ internally in the back-end of a kernel module.
That said, if we discuss why C++ isn't used throughout the kernel --- I understand your point. One remark though: about your first paragraph, one might turn the argument upside down and say that C is evil because a function named print_hello() may actually do a lot of malloc's and send a network packet too ;) The difference between C++ and C here is that functions in C++ may appear is more various forms than in C (operators, constructors, etc). It's really a matter of knowing what to expect: an experienced C++ programmer will understand spontaneously when an operator+ is likely to have to allocate memory for the result. Which takes us back to what is really Linus' best argument against C++ throught the kernel, and to your last paragraph... in other words, we agree.
Writing kernel modules in Haskell Posted Sep 14, 2009 6:13 UTC (Mon) by drag (subscriber, #31333) [Link]
Well a module is still just a hunk of the kernel and for best results, long-
term, it should be every modules goal to get integrated into the kernel proper. Therefore its counter productive to use any language other than the C version that is acceptable by the kernel folks.
Now the haskell thing is a interesting experiment and as such it does not
Writing kernel modules in Haskell Posted Sep 14, 2009 15:17 UTC (Mon) by bfields (subscriber, #19510) [Link] they are arguments against using C++ throughout the kernel, and hardly constitute an argument against using C++ internally in the back-end of a kernel module. I don't see how you're using that distinction. The bulk of the kernel is drivers. If drivers were written in a variety of languages, that would make the drivers as a whole more difficult to maintain.
Writing kernel modules in Haskell Posted Sep 14, 2009 7:36 UTC (Mon) by alankila (subscriber, #47141) [Link]
Quibble: a = b can be a struct copy. It will turn into a memcpy, if I recall correctly.
Writing kernel modules in Haskell Posted Sep 14, 2009 13:20 UTC (Mon) by cesarb (subscriber, #6266) [Link]
Oops, you are right, I forgot about that trick (which I have already used several times myself). Let me rephrase then: "a = b" in C can only mean the equivalent of a simple MOV for each byte of the variable (that is, it will read from each byte of "b" once, and write to each byte of "a" once; of course this will be optimized to read/write several bytes each time). The performance characteristics are still quite transparent.
Writing kernel modules in Haskell Posted Sep 14, 2009 21:27 UTC (Mon) by alankila (subscriber, #47141) [Link]
Yes. I fully agree with your basic argument.
Since Java is sort of C++'s successor, perhaps I can be justified to drag it into this discussion. There is something fairly nice about its way to have essentially two languages in it: a simple unextendable arithmetic language for doing underlying operations with -- no confusion possible about what any of the expressions mean and it's analogous to C -- and an object language which is used for extending the core language. It has plenty of the good parts of C++, I guess, but I would agree that it's far from perfect.
However, the discussion we are having now can not occur in Java. In fact, since defining classes is the only possible way you can extend Java in any sense of word, you are even encouraged to not know or care what happens behind a method. It's an unusual dichotomy, but I must agree that it works. It's sort of brilliant, even.
(I'm watching myself turn into a Java enthusiast. Oh dear.)
Writing kernel modules in Haskell Posted Sep 16, 2009 2:37 UTC (Wed) by ringerc (subscriber, #3071) [Link] (I'm watching myself turn into a Java enthusiast. Oh dear.) I'm suffering the same pain. Built-in GUI toolkit (even if it's pretty dire), sane and complete libraries, native Unicode string class (do not mention std::wstring in my presence), no build system pain, solid built-in threading and concurrency ... I'm getting to like it. I really miss RAII, though. It's not really possible in Java as there's no way to ensure a dtor fires reliably when an object exists scope, as with stack-based instances in C++. It's a real shame and a pain point for me, as working with program flow when exceptions are involved is excruciating without RAII. If I'm missing something and there's a reasonable way to do or approximate RAII in Java, please let me know...
Writing kernel modules in Haskell Posted Sep 17, 2009 6:10 UTC (Thu) by pynm0001 (guest, #18379) [Link]
Just like I wouldn't write C without one of glib or apr, I wouldn't write
C++ without Qt. Just as an aside, Qt has a built-in GUI toolkit (not dire, btw), sane and complete libraries (although not as comprehensive as Java I'd imagine), a native Unicode string class, minimal build system pain (usually as easy as qmake -project && qmake && make), and solid built-in threading and concurrency.
And you get RAII.
Writing kernel modules in Haskell Posted Sep 15, 2009 9:42 UTC (Tue) by etienne_lorrain@yahoo.fr (guest, #38022) [Link]
> of course this will be optimized to read/write several bytes each time
Do not be so sure of this "of course", for instance GCC:
I have to say that older compiler version were copying fields of structure more efficiently, because they were not optimised to compile
Writing kernel modules in Haskell Posted Sep 18, 2009 1:25 UTC (Fri) by kbob (guest, #1770) [Link] Even a seemingly simple statement like "a = b + c;" can allocate memory in C++, while in C the only way that statement will allocate memory is if the compiler has to spill registers
#define a (buf[read(open("/dev/hda", 0), buf, sizeof buf) - 1])
#define b (send(some_sock, buf, sizeof buf, 0))
#define c (system("xloadimage /usr/share/cups/doc-root/images/smiley.jpg &"))
You were saying?
|
|
||||||||||||