On 30/08/13 12:45, Chen Gang wrote: > On 08/30/2013 05:16 PM, Tomi Valkeinen wrote: >> So, in my opinion: >> >> - Normally we should presume the the stack is not corrupted, or >> otherwise we'll end up with lots of checks all over. >> > > It seems the above reply "Hmm... it really has quite a few same cases > ..." is suitable for discussing with your opinion. Well, if other drivers do silly things, it's no reason to do it here also. > >> - Even if i740_calc_fifo() is a static function, and we can analyze the >> _current_ situation, we don't know how the driver will evolve in the future. >> > > For normal static function (not callback function) it can be in control > within inside (ourselves), don't like extern function, it is out of > control with inside. > > So we can assume something in the future. We can assume that only if we presume that the future changes are bug-free. But more often than not there are bugs in the kernel drivers. Now, say, if such a bug is introduced, and somebody is running the kernel in a remote server, the driver will call BUG(). This will cause the server to halt. The user won't see what happened, the connections are just lost and the error is not written to a hard disk. If, instead, the driver would do WARN, and continue or fail in a controlled manner, the user can find out about the issue easily. Even if there is a stack corruption, it's most likely the driver in question that has it, and thus not really fatal. Sure, there's the possibility that there's a bigger memory corruption, which would go unnoticed by, say, the filesystem layer, resulting in a corrupted filesystem. And we would catch this corruption by checking the bpp variable. But, really, I find that very unlikely scenario. Here's some old discussion about BUG: http://yarchive.net/comp/linux/BUG.html Tomi
Attachment:
signature.asc
Description: OpenPGP digital signature
