lkml.org 
[lkml]   [2000]   [Oct]   [15]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Criticism] On the discussion about C++ modules

    C++ in kernel development should be discouraged in general. Structured
    Exception handling would be a nice C++ implementation in Linux, and the
    way the FS is using the name : function construct for the VFS function
    tables is very nice as well since we don't have to align the strucures.
    There are some elements that are attractive, but overall, why would a
    device thread want to allocate memory from an interrupt -- it could
    accidentally call one of your functions and use more stack or system
    memory, and make performance suck by increasing memory bus activity
    needlessly with all these little pieces of memory all over the place
    being allocated and written.

    Chorus was a C++ Kernel and a very good one at that the C++ layering all
    over the place and B2 level security features, but it was uninteresting
    too customers and did not achive mainstream adoption.

    :-)

    Jeff

    Eray Ozkural wrote:
    >
    > "J . A . Magallon" wrote:
    > > I agree that C++ for kernel is not a good idea, libstdc++ should be in the
    > > kernel,
    > > code would be bigger, there's a complicated runtime under C++ doing things
    > > by itself (copy constructors-operators and so on), inheritance adds some
    > > little calling overhead.
    > >
    >
    > You can profile C++ code very precisely. Avoiding copy constructors
    > is programmer's part. C++ doesn't require you to use polymorphism,
    > and if used carefully doesn't incur significant overhead.
    >
    > I can't say whether putting libstdc++ in a kernel module is a bad thing
    > before I see one. This is a skel. code:
    >
    > orion:opt$ ls -al app
    > -rwxrwxr-x 1 exa exa 14275 Oct 16 04:38 app
    > orion:opt$ ls -al /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
    > -rw-r--r-- 1 root root 271528 Oct 10 09:54 /usr/lib/libstdc++-3-libc6.2-2-2.10.0.so
    > orion:opt$ ls -al /usr/lib/libstdc++-3-libc6.2-2-2.10.0.a
    > -rw-r--r-- 1 root root 476494 Oct 10 09:54 /usr/lib/libstdc++-3-libc6.2-2-2.10.0.a
    >
    > It seems to me that a somewhat big module binary wouldn't hurt
    > for many applications. Putting that into the "real" kernel isn't
    > a good idea of course.
    >
    > Can't the unused code be stripped from libstdc++ for a single
    > kernel module? :(
    >
    > > - <const &> args : dont break your untouchable data, and get rid of pointer mess
    >
    > and const functions. This is such a good thing, it allows the compiler
    > to make great optimizations that are not possible in C. The C9x
    > standards had (IIRC) a similar "restricted" keyword for C, but
    > I don't know if gcc is going to implement it. You might want to
    > demand that from gcc developers :)
    >
    > > Perhaps a g++-embedded mode could be the solution...
    >
    > For embedded applications? ;)
    >
    > Regards,
    >
    > --
    > Eray (exa) Ozkural
    > Comp. Sci. Dept., Bilkent University, Ankara
    > e-mail: erayo@cs.bilkent.edu.tr
    > www: http://www.cs.bilkent.edu.tr/~erayo
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2005-03-22 12:41    [W:4.045 / U:0.088 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site