On Sat, Sep 30, 2006 at 11:09:54PM +0100, Jeremy Harris wrote:
> Bryan Cantrill wrote:
> >We will never be doing this: it violates the safety constraint, in
> >several dimensions. (One of which you outline below.)
>
> I'm interested - which other dimensions do you have in mind?
What if someone puts bad ECC on the text or data required to execute
the bad ECC handler? How does DTrace know what this text and data are
to prohibit it? More generally, what if someone puts bad ECC on text
or data that needs to be accessed at TL>1? How is this handled?
And what about memory that DTrace itself uses to (for example) store the
lookup table to know how to correct the bogus bad ECC? Most generally,
how can one prevent bad ECC from being placed on any word of memory that
is accessed in a context in which a correctable ECC trap cannot be
handled? Trust me that this is tricky -- and made much more so by this
idea, as it creates many more memory accesses from the correctable
handler.
And all of these issues are in _addition_ to the issue that you mentioned:
that by introducing bad ECC, you have lowered the fault tolerence of
those words that you are marking. This alone is unacceptable and a
violation of the safety constraint; the many other issues with this idea
are just the nails in the coffin.
- Bryan
--------------------------------------------------------------------------
Bryan Cantrill, Solaris Kernel Development. http://blogs.sun.com/bmc
_______________________________________________
networking-discuss mailing list
[email protected]
