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

[Haplo]

Well, about point C. I was afraid you'd say something like that,  
which is why I have this compelling argument prepared :P.
1:I agree fully, the right thing to do is obviously to fix the code,  
but this adds convenience for while that code is being fixed. Even on  
MacOSX you'll occasionally run into a bad driver that causes a kernel  
panic. The panic isn't a problem in coyotos, but errors will happen  
and crashes will result, and a healing layer simply greatly reduces  
the inconvenience. Also with the latter part of C, it could be  
optionally made to provide convenience in fixing that code. In a  
perfect world there's no place for a healing layer, but that's a very  
"Linus" way of looking at it.

2:It's explicitly stated that your initial target application will be  
mission critical applications. Now, to say that people developing  
drivers for such applications will very carefully design and test  
them would be accurate. To say that they would be entirely error free  
is optimistic. Optimism isn't really appreciated when people's lives  
or millions of dollars might be at stake, and in this case the  
healing layer provides a level of protection against a worst-case  
scenario. I'm pretty sure that's something which CAN be appreciated  
by that particular audience.

about A:
That would depend on the implementation, but the various nuances of  
that are beyond the current scope. We can discuss that when you come  
to it.

about B:
Well, that wasn't exactly a very resolute response. The big question  
is, how would it fly on x86 and popular RISC architectures? On one  
hand, it could be a big win for IPC performance, but only if there's  
a wide enough scope of "yes".

As for them being disk structures, I'm quite aware of that. The  
question is how often would they be on disk and how often in resident  
memory? If they're typically only on disk for persistence, then the  
question becomes the serialization cost.

There's a lot of factors here, but it still might be useful enough to  
consider.


On Jul 12, 2006, at 5:04 PM, Jonathan S. Shapiro wrote:

> On Wed, 2006-07-12 at 16:53 -0400, Haplo wrote:
>> A: Software feedback based scheduling. This seems like a good idea to
>> me. Priority based scheduling is just too limiting, and in the end it
>> all ends up "best guess" or the more common case is that most non-OS
>> associated apps are all given the same priority...
>
> Yes, and software-based feedback is extremely attractive. The problem
> with it is that it provides all applications with an unauthorized
> communication channel.
>
> We definitely need to look at this. I just wanted to point out that  
> it's
> not a simple thing to do in a secure and robust system.
>
>> B:Executable data structures. This has limited use but could still
>> provide improvement. In this case it would be more like instantiating
>> an object than dynamically generating code. The most specific example
>> of where this might be useful - that I can give at least - would be
>> capability register pages. If a page can only hold a certain number
>> of indices, then in-lined code that "knows" about the capabilities
>> it's managing could traverse them quickly and return the capability
>> at the selected index....
>
> Remember that the capability pages are *disk* data structures....
>
> If you look at the HDTrans work, you will find that we know about
> executable data structures. Sometimes its a good thing, sometimes not.
> For the HDTrans sieve, it was a huge win.
>
> The problem is that the benefit for this type of data structure  
> tends to
> be *extremely* dependent on the target CPU. Executable structures make
> great sense on IA-32 mainly because they let you avoid changes to
> condition codes (which are expensive). On other architectures, the  
> case
> for them is much less clear.
>
>> C:Something not really synthesis related that I didn't mention
>> earlier for various reasons. A self-healing layer like in Minix-3.
>
> In 30 years of operating KeyKOS and EROS, we have yet to observe any
> real case that motivated a healing layer. The right thing to do is fix
> the code.
>
> Separately, you should know that Minix doesn't deserve credit for this
> idea. It's a *very* old idea. Goes back to at least 1957 that I know
> about.
>
> shap
>
> _______________________________________________
> coyotos-dev mailing list
> coyotos-dev at smtp.coyotos.org
> http://www.coyotos.org/mailman/listinfo/coyotos-dev