making SW_WATCHDOG dynamic

[Mike Karels]

> > 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?

I understand what you are saying, but let me add some context.  The
watchdog driver and framework are part of the base system, and
SW_WATCHDOG is about a dozen lines of code embedded in hardclock.
So about 90% of the facility is already in the base system, and I
propose to make it 100%.

> 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.

I agree with using loadable modules more if they can be selected
automatically, e.g. Warner's work.  Keeping dozens of drivers out of
the base, and not having to edit loader.conf to include all the
desired facilities, is a big improvement.

> 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.

As noted, this is tiny, and the hooks to hardclock to connect to
the module would be about the same size as the current code.  The
advantage of the SW_WATCHDOG facility is that it is deeply embedded,
requiring only that hardclock be running.

> 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.

I'm not sure I agree with this goal, although I used to run custom
kernels quite often to save space.  That is less of a goal on x86
than in the past, and device drivers are the real bloat.  I don't
think that a large fraction of FreeBSD users build custom kernels,
although I don't have actual data.  But even in 4.xBSD days, many
systems ran the generic kernel.

		Mike