[lkml]   [2000]   [Jul]   [13]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Object Oriented Linux
In <> Tom Leete ( 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
>> 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
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:57    [W:0.118 / U:6.044 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site