[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.027 / U:9.468 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site