Follow Slashdot stories on Twitter


Forgot your password?
DEAL: For $25 - Add A Second Phone Number To Your Smartphone for life! Use promo code SLASHDOT25. Also, Slashdot's Facebook page has a chat bot now. Message it for stories and more. Check out the new SourceForge HTML5 internet speed test! ×

Submission + - iSCSI support for UNMAP (

gdamore writes: "illumos introduces support for SCSI UNMAP in the open source OpenSolaris derived kernel. This will help folks using thinly provisioned storage in VM deployments. The feature comes courtesy of Nexenta, and will be part of their next product release."

Wii 2 Delay Is Hurting Nintendo 310

BanjoTed writes "Michael Pachter's ongoing spat with Nintendo regarding the Wii 2 is well documented. Pachter is sure it's coming, Nintendo says it's not. Now the analyst has gone one further by claiming that the declining sales of the Wii documented in the platform holder's recent financial statements will only get worse unless it speeds up attempts to get its successor to market. He said, 'The reason for this is clear: the software being created is just not interesting enough or compelling enough to drive Wii owners to buy more than two [games] per year, and most of those purchases are first party software. We can blame the third party publishers for making shovelware, or for misjudging the Wii market, but the simple fact is that the publishers have to develop completely separate games for the Wii because its CPU is not powerful.'"

Comment Re:Better recovery... (Score 1) 411

Anyone here do kernel programming?

A common practice in kernel programming when encountering a totally unexpected situation is to "panic". The unexpected situations where this is acceptable are often one of two classes:

1) critical failure of a critical piece of hardware (e.g. your root disk going out to lunch), uncorrectable memory errors (but detectable), etc.

2) programming errors. (generally "bugs".) When developing code that makes certain assumptions, its often a good idea to validate those assumptions with something called an "assertion". (For example, an assumption that a linked list is properly terminated can be checked, or that the caller owns a particular lock, etc.)

In both cases, the response is to "crash" (or "panic").

Why do we do this? First, we've encountered a situation from which we do not have any realistic hope of recovering... so rather than risk data corruption or worse problems later down the road, we crash, to "stop the hemorrhaging" so to speak.

Second, this a good panic will also cause a dump of the system state to be taken, so that it can be analyzed later. In the case of hardware failure, it may give some clue as to what the bad component is that needs to be replaced. In the case of a programmer error, it often provides the details necessary to find and fix the bug.

Its not unreasonable to believe that situations like this could come up for application programs as well.

However, one thing that is _unacceptable_ for a kernel to do, is to crash just because a user happened to send bad input, or a network happened to spew bad data. (Errors _inside_ the chassis can cause a panic... errors from _outside_ the chassis should not.)

I think M$ have some debugging to do...

Slashdot Top Deals

try again