Messages in this thread | | | From | "Khimenko Victor" <> | Date | Thu, 13 Jul 2000 19:32:55 +0400 (MSD) | Subject | Re: Object Oriented Linux |
| |
In <396D877D.77E4D97A@mountain.net> Tom Leete (tleete@mountain.net) wrote: TL> [Cc. trimmed]
TL> Andrew Morton wrote: >> >> Khimenko Victor wrote: >> > >> > Kernel lacks suppot for rtti and exceptions.
TL> Why would anybody expect C code to catch exceptions? Define TL> an unexpected_handler, then:
TL> extern "C" int sys_func() // user context TL> throw() TL> try { TL> //do things TL> return 0; TL> } TL> catch( std::bad_alloc e) TL> { TL> return -ENOMEM; TL> } TL> catch( etc) TL> { TL> return -ETCETERA; TL> }
Have you TRIED to use such code in kernel ? WHO will generate std::bad_alloc in first place and HOW it will be done ? Have you EVER thought about how it's done in userspace ? Try: -- cut -- $ nm test.o U _._9bad_alloc U _._9exception 00000000 W __9bad_allocRC9bad_alloc 00000000 W __9exceptionRC9exception 00000000 ? __EXCEPTION_TABLE__ 00000000 ? __FRAME_BEGIN__ U __check_eh_spec U __cp_pop_exception U __eh_rtime_match U __start_cp_handler U __tf9bad_alloc U __throw U __vt_9bad_alloc U __vt_9exception 00000000 t gcc2_compiled. 00000000 T sys_func U terminate__Fv -- cut -- What's all this __check_eh_spec, __cp_pop_exception, __eh_rtime_match, __start_cp_handler, __throw, .. undefined things mean ? Answer: it's exception-suppoting stuff in libgcc.a . C++ reliaes HEAVILY on it's standard library (I mean NOT libstdc++ here but C++ support part of libgcc.a). MUCH more heavily then C. It's FAR easier to produce unefficient (time/code or stack) code with C++ and you will need to redo kernel version of libgcc.a. So C++ is REALLY foolish in kernel (not impossible, just foolish).
>> g++ -c -O -fno-exceptions t.cc >> size t.o >> text data bss dec hex filename >> 21 0 0 21 15 t.o
>> This is a red herring. All of it.
>>> Kernel lacks suppot for rtti and exceptions. ^^^^ ^^^^^^^^^^
>> See above.
And what I should see "above" ? I see code WITHOUT *rtti* and compiled WITHOUT *exceptions*-support. What it proves ?
>>> "Linux is free software"
>> Yup. And one principle of Free software is "don't tell other people >> what to do".
... unless they what something from you. That's right. If you want to do something for yourself or you want to create and support separate version of program you can do it. If you version will be REALLY better then original then everyone will use your version and original version will be abandoned eventually (recent example is this egcs/gcc stuff). But if you want to incorporate ANYTHING in original branch of ANY product (be it gcc, emacs or linux kernel) you MUST play by maintainers rules. Sorry, Andrew. You mixed up "free software" and "anarchy". Free software is NOT anarchy. Never was, never will. There ARE exist projects where development looks almost like anarchy. They suffer A LOT from than.
>> >> I'm sorry, Victor but this one gets under my skin. If people want to >> write kernel code in C++ well good for them. All it requires of the >> kernel developers is to take the darn C++ keywords out of the headers. >> About an hour's work for someone who has a license for /bin/vi.
Not at all. C++ is tied to it's support library MUCH more tight than C. And if we do not even want long long division to be supported in kernel then how the hell we can want to support all this stuff just to allow more complex and cryptic errors ? MAY BE (just "may be"!) you can use C++ to write decent kernel. But just taking of existing kernel and plugging C++ module in it is just plain stupid thing to do.
TL> Been there, done that, got the hairshirt. ;-)
Yeah ? You REALLY managed to write kernel module in C++ AND load it in kernel ? Full-blown C++ with exceptions and so on ? Hard to believe but even if so we still have question: what is it good for ?.
TL> The patch was huge (730k) and nearly all trivial. Takes more TL> than an hour if you're careful about not changing language TL> in comments.
TL> The resulting kernel ran just fine.
With C++-written modules ? Hmm.
>> This is an ideological language war masquerading as a technical and >> supportability issue.
Sorry. It's not. Situation is VERY simple indeed (if you'll stop searching for idealogy). Kernel is written in GNU C subset. Not even in "plain" C but on some specific subset of GNU C (it's using GNU C extensions but some features like long long division are not available; standard C library is not available at all - insted you should use some replacement functions) C++ is alien for kernel (just like Ada or Objective C). To use it you must add it's support in kernel (exceptions, allocations, etc...). It's NOT "hour's work for someone who has a license for /bin/vi". It's more like "full-blown research project". And it's not really clear what benefints you can get from such project: you can not use advanced features of C++ like exception freely anyway - for that you need full kernel rewrite to use exceptions (or at least exception-frendly code) everywhere (and there are A LOT OF places in kernel not ready for stack unwinding). C++ library use allocations in a lot of places invisible for programmer so you can easily add very inefficient code to kernel and not even notice it. So C++ library is out of question - you need replacement as well. And so on and so on.
And of course the are question: why C++ ? Why not add suppot for Objective C, Pascal, Ada, Modula-2, Fortran and Java (via GJC, of course - bytecode in kernel is still other issue) as well ? What ??? Are you saying "it'll be a monster and nobody will use it" ? How so ? Why addition of C++ will not make a monster while adding of few other languages will ? ONE language is enough for kernel. And it's NOT C++ but GNU C subset (see above).
TL> Yup. C99 'inline' is going to break things. Storage class TL> modifiers are plain out. They should continue to work for TL> gcc keyword __inline__.
Let's wait for C99 support in gcc and see. Perhaps some things in kernel will need adjustement - it's not first time and not last time when kernel need adjustement for new version of gcc.
TL> Cheers, TL> Tom
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |