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/
This archive was generated by hypermail 2b29 : Thu Sep 07 2000 - 21:00:24 EST