Re: [Syllable-kernel] Arno's kernel patches

[Jake H. <jh...@po...>]

Arno Klenke wrote:
> 
> My syllable installation has crashed so I currently cannot access the 
> patched kernel code that is on another afs partition. Please give me 
> some days to reinstall my system. To the cli()/put_cpu_flags() removal: 

I'm sorry to hear that.  One safety measure that I've taken is to 
perform regular backups of my Syllable partition to DVD-RW using Nero 
BackItUp from Windows, part of Nero 6 ultra edition.

> The current instability of the kernel cannot be caused by these removals 
> because Vanders also reports the same crashes when using the cvs kernel 
> code which still contains these calls.

That makes sense.  I suspect that our problems break down into a couple 
of categories:

1) 32-bit signed/unsigned comparison issues.  The current code is a bit 
cavalier about doing pointer arithmetic using uint32's and int32's.  As 
we push our 32-bit systems to the limits of memory capacity (4GB or even 
higher with PAE 36-bit addressing), it's important to be careful here, 
especially since we know we have bugs on large memory systems.  I'm 
about 90% complete with a fairly major search-and-replace job to convert 
the kernel to use the standard and more descriptive C99 types, such as 
uintptr_t and size_t instead of uint32, or the Syllable-specific types 
like status_t for return values instead of int.  This will prepare us 
for 64-bit support, but will screw up everyone's diffs from the current 
kernel.  Hopefully, by the time your Syllable installation is set up 
again, you can start hacking from the new, stronger-typed sources. 
Daniel is probably the only other person who will be impacted by this, 
but I'll post the diffs here at least a week in advance of committing 
them to CVS so we can merge our patches.

2) GCC sometimes inlines, sometimes doesn't inline, functions marked 
"inline".  I thought it would be better to write more functions as 
static inline, rather than as #define macros, but it now seems that some 
of these functions only work correctly when inlined, e.g. the inline 
definition of Fork() in init.c.  And now it appears there are others 
that only work correctly when not inlined.  Perhaps changing the 
performance by inlining, even though either version should be correct, 
is exposing race conditions or other timing issues on SMP systems.

3) Pre- and post-conditions.  We should have some standard convention to 
document pre- and post-conditions for calling a function (such as that 
interrupts must already be disabled), presumably in the doxygen, as well 
as using asserts more aggressively to verify these conditions, as well 
as any loop invariants.  This will help us to catch any incorrect 
assumptions in function usage.

-Jake