timeless wrote: >> Is the entire system stability threatened because of these unexpected >> flags? >> > > probably. if you have an application writing stuff, and it thinks it > successfully wrote it, and then its next step is to delete something > else, and the writing won't behave correctly because it doesn't > understand what it's been asked to do > > say you're doing: > <move, HOMEDIR, ARCHIVE> > > And maybe the flag that you were passed meant _you_must_do_this_sync_, > but you didn't understand that flag > > So the extension prepares a move (async), lets the callee think it > succeeded (because it didn't understand this special api), and the > callee then deletes HOMEDIR. > > Well, you lost everything :). > > Panics have uses. >
That's a good point, but regarding file systems and storage devices there are already a lot of ways that calls to 'open' 'read' etc. can fail. None or very few of these calls can be considered to always work under all circumstances. Any caller that assumes that an 'open' call or a 'write' operations always succeeds without checking for errors has some serious issues. :) For an extreme situation, what if I manage to clumsily pull the cord from my external drive at the same time that a file system call involving this drive is being made? I wouldn't want a kernel panic just because of some internal unexpected state occurring at that point. Same situation when a network based file system loses connection. > FWIW, I'm generally opposed to crashes and panics, but they really are > necessary at times, and for things where you're essentially accepting > a flag that could change how your module is supposed to behave, you > really can't just ignore it. > > Now, if the api call is early enough, you could refuse to load, or > force yourself to unload. but if it's in the middle of things, you > probably can't. > > It'd be bad if the reverse happened, <move, ARCHIVE, HOMEDIR/data> and > then <unknownmethod>. If unknownmethod decided to unmount the volume > or change its behavior and that affected the currently running move > ... well it's bad. > Yes, quite true. Still, with file systems, most operations can return an error code if something goes wrong. This is of course not true for kernel development in general, but file systems are creatures whose operations are mostly "allowed" to fail gracefully. >> In that case I can understand the panic, but intuitively it seems >> like something that it would be possible to recover from. >> > > fwiw, i'm not really into driver development. i try to stay at the > browser layer, but i get used to debugging drivers which crash because > of bad input. > > It's better to recognize bad input and fail fatally than not recognize > it and be exploitable (which is actually why i'm on this list). > I see your point. I'm not much into kernel development myself (not at all on Mac OS X), I'm just trying to understand the design decisions made in these cases. 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, so I would assume that every effort is made to strengthen kernel code to be able to withstand any bashing that surrounding code might subject it to. :) I can definitely understand though, that kernel panics are neccessary when you can't guarantee that the system is in a valid, defined state. I'm not questioning that. Stopping a system before it starts to misbehave in an undefined way is of course neccessary. Either way, thanks for an enlightening discussion. :) - Erik --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
