making SW_WATCHDOG dynamic

[Rodney W. Grimes]

> 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 at freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arch
> To unsubscribe, send any mail to "freebsd-arch-unsubscribe at freebsd.org"

-- 
Rod Grimes                                                 rgrimes at freebsd.org