From owner-freebsd-arch@freebsd.org Thu Dec 28 01:48:21 2017 Return-Path: Delivered-To: freebsd-arch@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1E568E8F3A9 for ; Thu, 28 Dec 2017 01:48:21 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-io0-x235.google.com (mail-io0-x235.google.com [IPv6:2607:f8b0:4001:c06::235]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D6B6E3634 for ; Thu, 28 Dec 2017 01:48:20 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-io0-x235.google.com with SMTP id f6so629594ioh.8 for ; Wed, 27 Dec 2017 17:48:20 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=OBRg/8xH8oMxNfbWx2Gh++b+dLXh/1zvXwkmk3wGSKE=; b=Pamt8H0LdTbFsbSQM0cfaQceNFO82kGkHZsDxzlcQvP4Kl78569hVtDYoNePLLffvu XoixCpgERkYQjcQzm6YICu6AGATLFEvXnKPun66OjXdGaM3yAoIwM0iuU6XOXQfFSeyX 7MopWwqBnmZh9AfM/nwRMdtaE+kNkMkOSguszvOF3wvPbVw6FuXAgLnYD3oG0/TvHWeJ SdLHFtAtL8HW6MiSl7PGzcx9UQXEyhwxlZPCMtjgagDZJ8cou5NBT+DT4yojztX5QWFs XWVQgRxu3lxRjT48QhXNqVd6ezPtkI6B4h9Ru3kb+LkV2PA4jJ2x9LZI1M1Igudw6x8g wDrQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=OBRg/8xH8oMxNfbWx2Gh++b+dLXh/1zvXwkmk3wGSKE=; b=Cgp9xPr7jk/Fqf3k0cViIG72YvmHdijs2jDoHsukSNYbJctENYugZQ1zjaLiYf9S/O llnuD5lo9Jtrfyuv1V63OpErR0MPvxkmM9LQ07tI9whwNdC//YzP1HfBjk4ycTh4i5dZ +hNhZWiBH0rjHIGoLTDbfkLZF4ZtDtfQRaWr1L5BE2UFxbZvdi38x2D7Vg/kKxU88hYh i3ZXi6pelEtFAteYaifpgzRp2gT0Wja1AeeaZVWADyQt2Aue38q0z+3eoSoKtT3jpnwI lqnE/0ZZKEFi+l6LMWiI/cpICRdAE3JaHhQjq7a1gNvY+Rd7tyMzzbDotSpHs6+ctfNS g6GA== X-Gm-Message-State: AKGB3mI+xkoxX8QXDOdxBwLVxf4l4ePYmM2mxhJnR2Ux/ajGqd/enLyT YoX25a5nUwlH0dxl+Jw6WmnkJGe/d5/C1pApWYkJfQ== X-Google-Smtp-Source: ACJfBotXqiBHEfGkJKdDMLVTdTZ80Mun6hG/dj5go7ADGx38W/aJHjGVULPBeIpjd5x2TxBjL7s1w9SYltws8CPqsI8= X-Received: by 10.107.183.202 with SMTP id h193mr17333087iof.291.1514425699009; Wed, 27 Dec 2017 17:48:19 -0800 (PST) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 10.79.108.204 with HTTP; Wed, 27 Dec 2017 17:48:18 -0800 (PST) X-Originating-IP: [172.58.56.94] In-Reply-To: <201712280117.vBS1HlMc017913@mail.karels.net> References: <201712271811.vBRIBqOK061996@pdx.rh.CN85.dnsmgr.net> <201712280117.vBS1HlMc017913@mail.karels.net> From: Warner Losh Date: Wed, 27 Dec 2017 18:48:18 -0700 X-Google-Sender-Auth: jZb1-DE7s7CviF9raTfN7IhsAmA Message-ID: Subject: Re: making SW_WATCHDOG dynamic To: karels@freebsd.org Cc: "Rodney W. Grimes" , "freebsd-arch@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.25 X-BeenThere: freebsd-arch@freebsd.org X-Mailman-Version: 2.1.25 Precedence: list List-Id: Discussion related to FreeBSD architecture List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 28 Dec 2017 01:48:21 -0000 On Wed, Dec 27, 2017 at 6:17 PM, Mike Karels 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