making SW_WATCHDOG dynamic

[Warner Losh]

On Wed, Dec 27, 2017 at 6:17 PM, Mike Karels <karels at freebsd.org> wrote:

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


Thanks for the vote of confidence :)

I don't view this as going the opposite way because of the very special
nature of SW_WATCHDOG. It doesn't fit into a nice, generic framework of
anything else.

> 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 agree here: It would be hard to recode as a loadable module w/o there
being an unacceptable hit to performance. Turning on the option wouldn't
have those issues.

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


The goal of my GENERIC weight reduction program is to reduce it by as much
as makes sense, but not beyond. There's several issues that will keep it
from being completely minimal. Consoles cannot be loadable modules, even
loaded from loader.conf. Storage devices that we're booting off of need to
be loaded before my code will run. And there's no good way to know we need
to load a certain driver in /boot/loader because the name space there
differs from FreeBSD's name space. We have to rely on heuristics that I've
not convinced myself will be sufficient, so there will be several storage
drivers in GENERIC until that problem gets solved. Plus root filesystems
need to be loaded, but at least that's knowable. There's also some geom
issues to sort out to make them loadable, especially in complicated
situations.

So all this is by way of saying that we have quite a bit of ground to cover
before even my limited vision is in place.

Warner