4 ms·

I want both. Panic in a test/development kernel, do not panic in a production environment.

• hutzlibu 9y ago
  Well, only that most devices never were tested over months in development kernel ... and it is not possible to do so, with all those million different devices around.
• snvzz 9y ago
  Absolutely panic in a production environment. Potential data corruption is far worse, so is a potential security compromise.
  • eeZah7Ux 9y ago
    It really depends on the use case! E.g. performing industrial control automation or airplane rudder control in a completely segregated network. You want control over these tradeoffs, not hardcoded behaviors.
    • snvzz 9y ago
      Linux is ill suited for that. Look at seL4, minix3, eChronos instead.
• TickleSteve 9y ago
  It the opposite... you should panic in a production environment and reset the state of the machine (which has become indeterminate). The correctness and validity of the data >> uptime.
  • pilif 9y ago
    As so often, it really depends. Let's say you've just detected that you're going to send incorrect data because you've ended up in an indeterminate state. If the remote end is going to ignore that data anyways, would it really be such a bad idea to keep running? Do you really want to go down in order to ensure that a remote who's ignoring your data can get correct data to ignore? Of course you never know what sort of effect the corrupt data is going to have, so it's always hard to make that decision. Like that issue with libraries linking against objective-c frameworks that has crept up with High Sierra and broke most of the Ruby world: Yes. The usage was incorrect. Yes, forking after threads are launched leads to undefined behavior, yes, knowing about it is a good thing. But: So far the crashes have been rare in the common use-cases (or they would have been fixed), so High Sierra's change to blow up loudly when it detects the misuse has actually caused a lot of trouble for people where things worked fine before. To the point where many Ruby developers were complaining about High Sierra "breaking" their workflow and recommending against upgrading. The new check is totally justified though. The existing forking behavior was wrong and it could have lead to crashes down the line. It didn't though. And now people are forced to fix something that was never an issue to begin with. It's a fine line to walk and while I generally prefer things to blow up as they go wrong, sometimes I catch myself wishing for stuff to just continuing to work. On some self-reflection, I come to the conclusion that I want my cake and eat it too.
    • TickleSteve 9y ago
      There rule I work to when I design these type of systems is that if the source of the error is internal you should reset and avoid propagating the error. Conversely if you receive an error from an external source you should handle it gracefully and reject the bad message.
  • kiriakasis 9y ago
    i use linux mainly to write latex these days, i don't want my kernel to panic, I do want my machine to stay operative and not corrupt my work. The kernel (for my intended usage) should intentionally panic only if there is a risk of corrupting my .tex files.
  • __david__ 9y ago
    On the other hand, the mere act of panicking may corrupt data (by virtue of stopping processes). I learned this the hard way when my kernel panicked while I was shrinking a large ext4 volume (the panic was unrelated to the shrinking). It's not just a simple equation like you've claimed.
    • TickleSteve 9y ago
      A panic should stop the processor dead, no data should be corrected as a result. Data in flight should not be used if you use transactional I/O and therefore will not be used if a write does not complete.
      • __david__ 9y ago
        That's fine in theory, but it didn't stop my disk from being corrupted. If the computer hadn't panicked, my data would still be available.
        • TickleSteve 9y ago
          its not theory... your system wasn't designed to be fault-tolerant in that manner. Systems that matter, are.
          • __david__ 9y ago
            The linux kernel needs to work with both tolerant and non-tolerant systems. Saying it needs to work a specific way that completely breaks real world things is completely naive, and exactly what Linus was railing against.