Date: Wed, 27 Dec 2017 10:11:52 -0800 (PST) From: "Rodney W. Grimes" <freebsd-rwg@pdx.rh.CN85.dnsmgr.net> To: karels@freebsd.org Cc: freebsd-arch@freebsd.org Subject: Re: making SW_WATCHDOG dynamic Message-ID: <201712271811.vBRIBqOK061996@pdx.rh.CN85.dnsmgr.net> In-Reply-To: <201712261425.vBQEPMmQ007578@mail.karels.net>
next in thread | previous in thread | raw e-mail | index | archive | help
> There is a kernel option, SW_WATCHDOG, which adds a low-level software > watchdog in hardclock. By default, the kernel and watchdogd support > only hardware-based watchdogs. There is also a callout-based software > watchdog that can be enabled by watchdogd with an ioctl if --softwatchdog > is specified, but watchdogd doesn't switch on its own. The SW_WATCHDOG > option adds a lower-level software watchdog to the hardware-based mechanism, > but it adds it unconditionally. I propose to include the SW_WATCHDOG > facility by default, but enable it only if there is no hardware watchdog. > I'm interested in any comments, suggestions, or background; feel free to > mail me off the list. If there are multiple people interested, I'll > forward messages to that group. > > I want to make the change because I have found SW_WATCHDOG quite useful > at $JOB, and it's annoying to have to build a custom kernel just for this > (not just once, but every time there is a kernel patch). This is not a good reason to include this code in GENERIC. Should I add all the things I find handy at $WORK too? Further I think this is going in the opposite direction of what we should be doing, less and less included in GENERIC, more and more done as loadable options. I think Warner (imp@) is going down this path with his devmatch code. Now if you can recode this functionality so that it is a boot time loadable module I am sure many would be very happy to have that! It would satisfy your need of not having to recompile a kernel, and others need of not needing this code at all. I think we have lost some light as to what the GENERIC kernel is really for, to get you up and running good enough that you can infact build a custom kernel. I do not think it was ever intended that people run this long term, though over the years that has become the defacto standard. IMHO, a bad one at that. > Also, I'm curious why we have two software watchdog facilities. The > --softwatchdog facility has various options on expiration, such as > printf/log/panic; I don't know why anything other than panic/reboot > would be desirable, though. I already contacted some of the people who > have left fingerprints on watchdog. Also, if anyone wants to review > the code, let me know. I have no idea why we have 2, but can hypothosize that 2 different people did the work, and both got included. As far as only action on a timeuot being panic/reboot, not sure I agree with that as we should provide a method (timeout has occured, what would you like to do) not a policy (reboot/panic). > Thanks, > Mike > _______________________________________________ > freebsd-arch@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arch > To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org" -- Rod Grimes rgrimes@freebsd.org
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201712271811.vBRIBqOK061996>