lkml.org 
[lkml]   [2004]   [Jan]   [20]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: Compiling C++ kernel module + Makefile
    On Mon, 19 Jan 2004, Bart Samwel wrote:

    > Richard B. Johnson wrote:
    [SNIPPED...]

    > into it and do useful work. If somebody has decided that it would be
    > worth it for his project to use C++ (without exceptions, rtti and the
    > whole shebang) then so be it, why should you care? It's just binary code
    > that hooks into the module interface, using the correct calling
    > conventions. It doesn't do dirty stuff -- no exceptions, no RTTI,
    > etcetera. It compiles into plain, module-interface conforming assembler,
    > that can be compiled with -- you guessed it -- 'as', the AT&T syntax
    > assembler. Yes, they're taking a risk. Their risk is that C++ can't
    > import the kernel headers, or that C++ might someday need runtime
    > support that cannot be ported into the kernel. It's *their risk*, not
    > yours. Then why do you have a reason to get religious about this?
    > They're not submitting this stuff for inclusion in the Linux source!
    >
    > > Any person, or group of persons, who is smart enough to
    > > actually write some kernel code in C++, has proved that
    > > they are not ignorant. Therefore, they have demonstrated
    > > their arrogance.
    >
    > This logic is faulty. It is built upon the premise that (ignorant ||
    > arrogant). Not listening to warnings of others is not a sign of
    > arrogance per se, it is only a sign of the presence of a different
    > opinion. It assumes that the kernel developers are always right, and
    > that everybody who is smart should listen to them, on penalty of being
    > arrogant. Yes, these C++-loving people may be wrong (or they may not
    > be), but that does not _automatically_ make them arrogant, they may
    > simply have a different opinion -- right or wrong. If they are wrong,
    > they are not arrogant, but simply *stupid*. If they are right, they are
    > not arrogant either -- they may be arrogant *about it*, but that's just
    > a manner of behaviour, and it's up to them if they behave in this way or
    > not. Kernel developers do not prescribe what people can do with the
    > kernel, this is part of the essence of "free". And as a result of that,
    > they do not have the right to declare people arrogant when they do not
    > listen. They have the right to *call* them that, but the only result of
    > that is that all discussion on matters like these are smothered in
    > religious wars. And that's a pity.

    It's not, as you say, a religious war.

    Whether or not one can use the back-end of a
    hatchet as a hammer does not qualify the hatchet
    as a hammer.

    Let me introduce the concept of a "learned person".
    Such a person might not actually exist. However,
    for my proposes, a learned person knows everything
    there is to know about solving the problem at hand.
    This is a definition. It is not subject to discussion.

    C++ was designed as an object-oriented language.
    C and assembler are procedural languages, as have
    been most all previous programming languages.

    The coding of operating systems is all about
    procedures. In fact, one of the reasons for the
    superiority of Linux is the great attention to
    the details of the actual execution mechanisms
    and the actual execution paths.

    An object-oriented language relies upon the
    compiler and libraries to work out the execution
    mechanisms to be used. The programmer is shielded
    from the actual mechanisms that implement the
    objects being manipulated. For instance, in C, one
    can code a loop counter and code the actual
    mechanisms by which a procedure may terminate. In
    C++, one may use iterators. Whether or not there
    is some actual counter is an implementation detail
    that can be hidden from the programmer.

    Of course one may also write C-like code when using
    C++ because there are some things that an object-
    oriented mechanism can't do by itself. This allows
    one to write loops with loop-counters in C++. The
    fact that C++ can be used somewhat like C does not
    make it a substitute for C anymore than a hatchet
    is a substitute for a hammer.

    Because of the object-oriented design of C++, there
    is considerable overhead necessary to make it function
    in an environment with many other objects. C has some
    overhead of its own, too. However, it is quite minimal.
    Local variable space is allocated simply by subtracting
    a value from the stack-pointer, for instance. The overhead
    of a particular language is often demonstrated by writing
    a simple "Hello World!" program in that language and then
    displaying the result as the size of the executable.
    This, of course, is quite unfair. It really shows how
    smart the linker is. A smart linker will link in only
    the required code. Linkers are pretty dumb.

    In the kernel, a linker doesn't have to be smart because
    the programmers have provided only the code that should
    be executed. There is no runtime library.

    Nevertheless, I provide three programs, one written in
    C, the other in C++ and the third in assembly. A tar.gz
    file is attached for those interested.

    -rwxr-xr-x 1 root root 57800 Jan 20 10:16 hello+
    -rwxr-xr-x 1 root root 460 Jan 20 10:16 helloa
    -rwxr-xr-x 1 root root 2948 Jan 20 10:16 helloc

    The code size, generated from assembly is 460 bytes.
    The code size, generated from C is 2,948 bytes.
    The code size, generated from C++ is 57,800 bytes.

    Clearly, C++ is not the optimum language for writing
    a "Hello World" program. Because many persons don't know
    assembly language, it is probably not the best language
    either, in spite of the fact that the executable file is
    only 460 bytes in length. Therefore a learned person,
    given the task of choosing the language in which to write
    "Hello World!" would likely use 'C'. In spite of the
    fact that it can be written in C++, I suggest, in fact
    insist, that a learned person would never write such a
    program in C++ except for the purpose of demonstrating
    that it can be done.

    When writing code for a project, one is not usually
    presented with a bunch of languages from which one can
    choose on a whim, or by throwing darts. Instead, there
    are specific requirements defined by the nature of the
    work to be done. There is no learned person who would
    require that a data-base project be written in assembler.
    It is quite likely that the optimum language would
    be C++. There might be certain portions of the resulting
    executable that, in fact, were written in assembler,
    probably a lot of the runtime library. When writing a
    data-base program, one absolutely positively must not
    know what the underlying data-fetching mechanisms are
    because, once known and used to define (poison) the
    design, the program may run poorly on a network. This
    is one of the areas where object-oriented programming
    really shines.

    However, when writing code that runs in an Operating
    System, one is most entirely concerned, in fact consumed
    with the mechanisms by which the required functionality
    is obtained. Programmers spend hours, days, even weeks,
    shaving microseconds off from critical execution paths.
    This is because any resources used by the Operating
    System directly affect every task running under that
    Operating System.

    A learned person would never allow the code, defined by
    the designers of a compiler, to make the final decision
    about the mechanisms necessary to perform the required
    functions. Instead, the Operating System programmer makes
    those decisions. That's why a procedural language must
    be used in coding Operating Systems.

    The result of such attention to details is the Linux
    Operating System.

    Now, if you want to trash your copy of the Operating System
    with the output spewed from a C++ compiler, then I suggest
    you keep it real quiet. It is similar to "touching up" a
    famous painting with spray-paint, of defecating on a wedding
    cake.

    Again, writing a Linux kernel module in C++ demonstrates
    arrogance, absolutely, positively arrogance, and is an
    affront to the programmers who have dedicated major amounts
    of their time optimizing code execution in the kernel.

    Cheers,
    Dick Johnson
    Penguin : Linux version 2.4.24 on an i686 machine (797.90 BogoMips).
    Note 96.31% of all statistics are fiction.

    [unhandled content-type:application/octet-stream]
    \
     
     \ /
      Last update: 2005-03-22 14:00    [W:2.807 / U:0.044 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site