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

[Haplo]

> 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.

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,  
but what defense do you have until then? I think they're probably  
much more likely to adhere to a simple specification that works to  
help them than they are to suddenly start adhering to a strict  
personal coding regiment.

Really, the idea is more of a realistic approach than it is an  
idealistic one.