[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  

It can be done with a (non-shared) library call. I think the kernel already
knows how to restart operations.
On the other hand the drivers live in user-land, it should be easier to
avoid crashes.

>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  

But the real picture of life-critical software is: if a hang is detected
probably you have few seconds of life.
In this situation, relying on a recovery mechanism is not better than
relying on the correctness of software.

>to be able to respond to the restart layer, but that would require  
>much less work than encapsulating every driver individually.
>
>Yes, there's no substitute for doing it right, but in the real world  
>people really do have deadlines and so they don't have time to write  
>self-restarting drivers or even produce drivers that aren't going to  
>crash. Yes, they may eventually revise it until the driver is stable,  

In the real world producing life-critical software correctly is not
compatible with deadlines.

val