lkml.org 
[lkml]   [2000]   [Sep]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    Subjectfrom binary towards source level scalability
    Martin Dalecki wrote:

    > Elmer Joandi wrote:
    > > strict standard template for linux kernel functions:
    > > INLINE(context,level,for_speed, fixed) returntype functionname
    >
    > Please have a tought look at the floppy tape streamer driver to see why
    > this is a BAD IDEA.

    Couldnt see much else than half of it being implemented.

    1. My point is more in source level scalability, whatever techincal
    way it is done. There is an natural potential for open source software
    which is not quite completely used.
    RedHat still ships i386 binaries which run 30% slower( and are still
    with debug info default on) than Mandrakes
    i586. Neither of them offers on-install automatic recompilation.
    Before imitation of commercial binary vendors they could think about
    using their native potential.

    2. About macroplay, if you dislike it: if few macros would be used all over
    the code, it would be very clear, cleaner than without them.
    Ftape driver trace macros have some
    strings in them :), if strings are forced , then someone gets to comment his

    code a lot more. It is just a matter of getting used to style.

    3. Lets assume for a while, that for every container(array, hash, btree) for
    which
    there is currently runtime dynamicly changeable default size or other
    parameter
    there would be a compile-time option to turn it static and compiled in with
    both intentions:
    a) to keep it small an operational on 386sx25(your cellular phone) and
    b) fast&memory-consuming on NxGB memory top-tuned SMP superbox.
    i.e. instead of
    #define MY_HASH_SIZE 123
    or #define MY_HASH_SIZE ((whatever)->size)
    there would be
    CONTAINER_SIZE(MY, 10, user_min, 40, 123, 1200, user_max, 10000)
    and it would by default compile to dynamically changeable 123, but could
    also
    be user-specified size or developer-specified minimum statically compiled in.

    And, would not go out of developer specified reasonable values.

    4. symbol, printk and other text-based information, inline regulation...
    all of those disputes wheter to have or not to have something new like
    that in kernel could just end up being configuration options.
    PRINTK(subsystem, module, level, "my networking whatever") could be
    elliminated
    by configuration option like: not verbose for subsystem=networking.

    Top dream would be to have enduser to specify his intentions(file,webserving,

    desktop,development) and then a program gathering memory and cpu speed-size
    info, generating proper kernel and libraries config and compiling it static
    then and doing some
    stress test just after that.That could be standard procedure for linux
    installation :)
    Instead of compiling it by hand and then getting 30% faster.

    On some places source code must not be an art, but just systematic
    structure or a bunch of data in table. Currently, for example, inlining
    is an artistic act. And debugging. And /proc interface. The other way
    would be to make it a configure-time option and/or flexibly
    configurable/dynamicly changeable.
    Then it would be compile-time art for distributors.

    elmer.




    -
    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:38    [W:0.025 / U:1.796 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site