Messages in this thread |  | | Date | Wed, 06 Sep 2000 04:01:08 +0200 | From | Elmer Joandi <> | Subject | from 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/
|  |