Hi Guenter On 25 May 2015 at 00:29, Guenter Roeck <linux@xxxxxxxxxxxx> wrote: > On 05/24/2015 09:13 AM, Timur Tabi wrote: >> >> Fu Wei wrote: >>> >>> in the first timeout, just panic() maybe not enough, in [RFC] >>> version of my patchset, I offer some option as "preaction" to use, but >>> for simplifying the first version of driver, I have deleted them. >>> but at least, panic() is far more useful than a simple reset. at >>> least, it can provide the context of the crashed system to admin. >> >> >> My point is that there is very little difference between >> >> 1) calling panic() on pre-timeout >> 2) calling panic() on timeout >> > > The assumption would be that the second timeout doesn't cause a panic > but a system reset. > >> In both cases, the system will panic. The watchdog API says that the >> system should reset when a timeout occurs, so you cannot call panic() before >> the timeout expires. >> >> > If you want to warn user space, that will make driver more >> > complicated, I don't think that is a good choose for a first version. >> > but we can find a way to improve this later >> >> In my opinion, this "first version" is not useful. I would like to see a >> pre-timeout feature that does not panic or reset when a pre-timeout occurs. >> > > The current watchdog API suggests that the pretimeout "allows Linux > to record useful information (like panic information and kernel > coredumps) before it resets". The call to panic() would be the > means to make this happen. Yes, that is what I mean. Great thanks for your explanation. :-) > > Are you suggesting to change this definition ? What should it do > instead in your opinion ? > > Thanks, > Guenter > -- Best regards, Fu Wei Software Engineer Red Hat Software (Beijing) Co.,Ltd.Shanghai Branch Ph: +86 21 61221326(direct) Ph: +86 186 2020 4684 (mobile) Room 1512, Regus One Corporate Avenue,Level 15, One Corporate Avenue,222 Hubin Road,Huangpu District, Shanghai,China 200021 -- To unsubscribe from this list: send the line "unsubscribe devicetree" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
