Richard,

Thoughts inline...

> [...]
>   
>>> BTW: From the C-standard, dereferencing a NULL
>>>       
>> pointer could also create
>>     
>>> pink smoke in your screen.
>>>       
>> Can I have the sourcecode for that signal handler,
>> please ?
>>
>> :)
>>     
>
> Undefined means _anything_ can happen, right?  :-)
>
> Back in the day, one _could_ destroy hardware with software
> (think disk drives the size and weight of washing machines;
> now think an unbalanced load during spin cycle).
>   

You certainly coule. Back in the 1980's I managed to destroy the screen 
of a Commodore PET by stuffing erant values into the memory-mapped 
regions related to the 6845 CRTC (CRT Controller); causing the entire 
video output o be condensed into a single vertical pixel-wide output in 
the centre of the screen. That was the end of that monitor :-(

> I suspect one still could, if for example thermal protection
> (shutdown on overheat) could be programmed to an unreasonably
> high value, and the fans turned off.
>   

You still can - I learned through darned nosiness (strings on the 
binary) more about the redx (Red Cross) utility on the E10K than any 
customer is supposed to - including how to reliably fry hardware. Never 
had the cojones (or personal financial stability)) to try any though ;-) 
In terms of temperature monitoring on the E10K, ISTR that the highest 
(worse) case of  component overheating was flagged as "911" (probably 
linked via a MODEM API to an imminent automatic Halon release in the 
datacenter ;-) )

>> On a historical note, mmap'ing MAP_ANON and fd==-1
>> only was introduced 
>> with Solaris 9 as far as I remember. Could've been
>> Solaris 8, but anything 
>> older I'm sure it required the /dev/zero "trick".
>>     
>
> It's in the partial Solaris 8 FCS source that was made available to anyone
> that asked for it (under restrictive terms) in src/uts/common/sys/mman.h.
>   

"Anyone that asked for it" is a tad loose... OK - the "restrictive 
terms" were having to adequately answer about 40 questions of all kinds 
to justify access..

Regards... Sean.


_______________________________________________
opensolaris-code mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/opensolaris-code

Reply via email to