On Thu, Dec 18, 2008 at 3:23 PM, Erik Larsson <[email protected]> wrote: > From the user's point of view, a kernel panic is the among the worst > things that can happen as you potentially lose everything that you're > currently working with,
everyone assumes this. but it's actually wrong. the worst thing is to have stuff you weren't working on corrupted in ways you don't recognize until it's too late :) and w/ a file system driver, stuff like that really could happen <insert plug for ZFS here, including some great videos, which can probably be loaded via youtubefs :)>. http://images.google.com/images?q=sad+mac (when your computer doesn't boot, you're a lot less happy than when it just reboots) wrt lost data, i've moved to using ff3 and googledocs (and gmail), which mean that my data is automatically saved while i'm not thinking about it. even computer games have autosave (although sometimes they intentionally don't for certain points) none of this means that i like it when my systems panic. i still have a bone to pick w/ a certain firewall vendor (i can't pick it w/ them because due to encryption below the os level, i can't get a dump for the panic). the good thing about panics in general is they upset customers and the customers send strong feedback and the engineers try to analyze (and fix) them asap. the other nice thing about panic markers in open source is that people are free to search for them and audit them to try to figure out what assumptions they're making - this is similar to what i was doing (i was searching for malloc/realloc, but looking for panic() is just as easy). if you think that a panic() could happen because of something legal, try to build a testcase - from what i've seen w/ macfuse, that should actually be tolerable (just save your work before you start ;-). and once you have a nice testcase which explains why the input should be legal and what the expected results are, you can file a bug (and maybe even try to patch it). > Either way, thanks for an enlightening discussion. :) :) thinking about open(x, 0), it sounds like a stat shortcut to search for bad files/paths EACCES, ENAMETOOLONG, ENODEV*, ELOOP, ENOMEM, EMFILE, ENFILE (* the explanation here makes no sense) i seem to recall code which did something like that (don't ask me where) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "MacFUSE" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/macfuse?hl=en -~----------~----~----~----~------~----~------~--~---
