lkml.org 
[lkml]   [1996]   [May]   [6]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
SubjectRe: ideas
Date
> but at a cost of speed. There are also more C wizards in linux land than 
> GAWK wizards. More people working on something, the faster it gets done, or
> the better it is, at least this is true of linux.

Go ahead and do it. Actually I suspect gawk will beat you or come very close.
Its virtually I/O bound and it beats gcc -M doing basically the same task.

> Interface lock for each version.

Ah locking in catastrophes. Bad. 1.2.x keeps the same internal interfaces
2.0.x should but not other things. The idea also doesnt work too well for
a kernel when things can change that are subtle and internal.

> 3. Use the features in C++ that will allow a more stable kernel
> Okay here is where i am going to get the developers mad at me. How about
> converting parts of linux to use C++, no not classes or the object
> oriented
> stuff, just the parts that can make life easier for the developer, and
> make
> the kernel run faster and more stable. Use default arguments, to

C++ code is currently slower and has buggier output than well written C (
especially as certain people bother to peek at the assembler output). Unless
the g++ walking volatile bug has finally been fixed its also not
usable. Finally g++ eats memory - forget building on an 8Mb machine with g++


> Also we could use C++ streams type functions to implement printk calls. I
> wonder how many drivers have been broken by stack corruption, by
> incorrect
> params in printk calls. Variable argument function calls are inherently
> slower then fixed argument calls.

But not than C++ calls or multiple calls or the other mess. I've not found
a single problem with printk, because gcc supports typechecking of printf's

Alan



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