Re: [PATCH] drivers: video: i740fb: add 'default' processing contents for 'switch'.

[Tomi Valkeinen <tomi.valkeinen@ti.com>]

[-- Attachment #1: Type: text/plain, Size: 1892 bytes --]

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 #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 901 bytes --]