[coyotos-dev] Hi + some stuff I found researching

[Valerio Bellizzomi]

On 12/07/2006, at 21.21, Haplo wrote:

>> Yes. And I don't really want to discourage you. I think that the right
>> response here is: let's get something that works and then see if (a)
>> there are places where this type of technique would make sense and (b)
>> the risk of introducing it is acceptable.
>
>Indeed, I like to call that "the development process". If I come up  
>with or come across anything that might be useful in the future I'll  
>be sure to mention it. Even if only one in ten actually turns out to  
>be viable it's still a good possibility for improvement. I can only  
>do what my ability permits, but at least I'm bouncing it off people  
>who are both knowledgeable and willing to listen. That's far better  
>than leaving it speculative or wrong on my own and then end up not  
>having anything good I find ever put to use.
>
>> Sure, but that wasn't my point. We have a commit rule on the Coyotos
>> code base that is carried forward from EROS: code doesn't go in to the
>> main tree unless the person making the commit is willing to bet their
>> life on it being right.
>>
>> We fail, of course, but it helps explain what the level of confidence
>> needs to be. Coyotos actually *is* about to go into surgical
>> instruments, so it's not just a joke.
>
>Which is a truly good way to go about programming in any case. My  
>point, however, was that coyotos isn't necessarily limited to that,  
>though. For example, one of your goals is to have it scale to large  
>SMP systems. This has nothing to do with a medical usage which is  
>likely limited to one single core chip. As long as something that  
>gives improvement elsewhere doesn't incur problems for the more  
>critical applications, it shouldn't be a problem. However, my lack of  
>general knowledge in the field is something you'll have to help with.  
>As I'm not to familiar with the specifics, very often I might not be  
>able to see such relationships.
>
>> A separate layer isn't needed, this can be done inside the driver  
>> without
>> introducing a new layer in the system. With a correctly engineered  
>> pre-test
>> cycle, the driver can be slower but it gains robustness.
>> One more reason to avoid drivers written in haste to meet the time
>> schedule. There is nothing better than testing and verifying by hand.
>>
>> val
>
>I suppose so, but if all drivers did that wouldn't it mean a lot of  
>redundancy in the system? Drivers would be less efficient than the  
>kernel+restart layer in detecting their own crashes, and you'd end up  
>with the same code in a lot of drivers and slow them down. The  
>healing layer wouldn't require direct observation or even need to run  
>during normal operation, so no performance penalty at all. The only  
>time it would be run is when invoked by the kernel when hangs are  
>detected. You'd still need an alternate driver specification for them  
>to be able to respond to the restart layer, but that would require  
>much less work than encapsulating every driver individually.

Two points are unclear to me:
1. It would end up with the main driver specification plus the alternate
specification, which requires more work for verification.
2. The healing layer is invoked by the kernel in a critical zone. There is
no performance penalty during the normal run, but there should be a
performance penalty exactly when you are in the critical zone.

val