From owner-freebsd-arch@freebsd.org Tue Dec 26 14:48:50 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 DD3E0E9398F for ; Tue, 26 Dec 2017 14:48:50 +0000 (UTC) (envelope-from karels@FreeBSD.org) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id A9A7E781F9 for ; Tue, 26 Dec 2017 14:48:50 +0000 (UTC) (envelope-from karels@FreeBSD.org) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.15.2/8.15.2) with ESMTP id vBQEPMmQ007578 for ; Tue, 26 Dec 2017 08:25:22 -0600 (CST) (envelope-from karels@FreeBSD.org) Message-Id: <201712261425.vBQEPMmQ007578@mail.karels.net> To: freebsd-arch@freebsd.org From: Mike Karels Reply-to: karels@FreeBSD.org Subject: making SW_WATCHDOG dynamic MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <7576.1514298322.1@mail.karels.net> Date: Tue, 26 Dec 2017 08:25:22 -0600 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: Tue, 26 Dec 2017 14:48:51 -0000 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). 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. Thanks, Mike From owner-freebsd-arch@freebsd.org Wed Dec 27 13:46:23 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 205C2E8E2F1 for ; Wed, 27 Dec 2017 13:46:23 +0000 (UTC) (envelope-from agapon@gmail.com) Received: from mail-lf0-f41.google.com (mail-lf0-f41.google.com [209.85.215.41]) (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 A61F6661E4; Wed, 27 Dec 2017 13:46:22 +0000 (UTC) (envelope-from agapon@gmail.com) Received: by mail-lf0-f41.google.com with SMTP id u84so22429756lff.7; Wed, 27 Dec 2017 05:46:22 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=3KMG0MRLXsbSmMObb/QjMMJ/KbseMjzSx5Z+SJkvJqg=; b=jeQB0srJCr9jEwM+O3SwkUfP6hW7I7aniiiWssL6Vjoc/151RSKqs3rsEHBHLC+wfG bbbXV0XmWuM9JjiJcTkdEJ3x/Skc32hjgEfzom5CC5aM2CnLFiPylexLVzDaQaEwd2N9 PyMHbkf1I4mfFO/h8OH7A3FuqUp3mj5JzsLXfT33yaHpszXeYBVUBFPfHddxjVn2VwaD B8ARQJL0Xncpj3fPwyEOPh3TjXr3eYuQU+tc8XGF+UkL8W37j+y7w9UwIldnUOFXLuek G3d27rARXmxKtoEeqr0P5k/1dpvfTBDaqlK6Pv41ZAN7d4bR4CxJTzMuOUmNAgevstjS 0kpQ== X-Gm-Message-State: AKGB3mI7vyI/6KD8pMlouLdVJxlrdvLL0v5LNPhvAFn7KpnxykBm0BWA dCsNxjxkP2CYUraD1KEtJ+y8gMvb X-Google-Smtp-Source: ACJfBouwfZka7e0KpqvwXvOOKNDUHuK9I5NuH7L6bZeQPs4c5mdtc9BlQj8l3N74Ll63ewa0dpY9TA== X-Received: by 10.46.89.129 with SMTP id g1mr17662792ljf.12.1514380735848; Wed, 27 Dec 2017 05:18:55 -0800 (PST) Received: from [192.168.0.88] (east.meadow.volia.net. [93.72.151.96]) by smtp.googlemail.com with ESMTPSA id b77sm3879050lfh.67.2017.12.27.05.18.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 27 Dec 2017 05:18:54 -0800 (PST) Subject: Re: making SW_WATCHDOG dynamic To: karels@FreeBSD.org, freebsd-arch@freebsd.org References: <201712261425.vBQEPMmQ007578@mail.karels.net> From: Andriy Gapon Message-ID: Date: Wed, 27 Dec 2017 15:18:53 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <201712261425.vBQEPMmQ007578@mail.karels.net> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit 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: Wed, 27 Dec 2017 13:46:23 -0000 On 26/12/2017 16:25, 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 think that this is a good idea. Although, I would not necessarily tie the software watchdog to not having any hardware watchdog. This is probably a good default policy, but I would allow to enable / disable the software watchdog explicitly (e.g. via a sysctl). I also think that we should support enabling several watchdog timers with different timeouts. Each of them can serve a different purpose. E.g., a software or hardware NMI-sending watchdog can be used to get diagnostic data out of a hung system while a resetting watchdog can be used to ensure fail-safe operation. > 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). Makes sense. > 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 guess that the second software watchdog was added to achieve what I suggested above. Of course, it would have been nicer to re-use SW_WATCHDOG for that purpose and to add a more generic support for configuring multiple watchdog timers with different timeouts. But I guess that adding a new single-purpose software watchdog was much easier to do. P.S. And maybe just using the second software watchdog would be good enough for what you are doing? -- Andriy Gapon From owner-freebsd-arch@freebsd.org Wed Dec 27 18:11:55 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 A02D7EA4FDD for ; Wed, 27 Dec 2017 18:11:55 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 76A076FDF6; Wed, 27 Dec 2017 18:11:55 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id vBRIBqZi061997; Wed, 27 Dec 2017 10:11:52 -0800 (PST) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id vBRIBqOK061996; Wed, 27 Dec 2017 10:11:52 -0800 (PST) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201712271811.vBRIBqOK061996@pdx.rh.CN85.dnsmgr.net> Subject: Re: making SW_WATCHDOG dynamic In-Reply-To: <201712261425.vBQEPMmQ007578@mail.karels.net> To: karels@freebsd.org Date: Wed, 27 Dec 2017 10:11:52 -0800 (PST) CC: freebsd-arch@freebsd.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII 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: Wed, 27 Dec 2017 18:11:55 -0000 > 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 From owner-freebsd-arch@freebsd.org Thu Dec 28 01:17:54 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 04A95E8BCF1 for ; Thu, 28 Dec 2017 01:17:54 +0000 (UTC) (envelope-from karels@freebsd.org) Received: from mail.karels.net (mail.karels.net [216.160.39.52]) by mx1.freebsd.org (Postfix) with ESMTP id A209716EF for ; Thu, 28 Dec 2017 01:17:53 +0000 (UTC) (envelope-from karels@freebsd.org) Received: from mail.karels.net (localhost [127.0.0.1]) by mail.karels.net (8.15.2/8.15.2) with ESMTP id vBS1HlMc017913; Wed, 27 Dec 2017 19:17:47 -0600 (CST) (envelope-from karels@freebsd.org) Message-Id: <201712280117.vBS1HlMc017913@mail.karels.net> To: "Rodney W. Grimes" cc: freebsd-arch@freebsd.org From: Mike Karels Reply-to: karels@freebsd.org Subject: Re: making SW_WATCHDOG dynamic In-reply-to: Your message of Wed, 27 Dec 2017 10:11:52 -0800. <201712271811.vBRIBqOK061996@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-ID: <17911.1514423867.1@mail.karels.net> Content-Transfer-Encoding: quoted-printable Date: Wed, 27 Dec 2017 19:17:47 -0600 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:17:54 -0000 > > 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 --softwatch= dog > > is specified, but watchdogd doesn't switch on its own. The SW_WATCHDO= G > > option adds a lower-level software watchdog to the hardware-based mech= anism, > > but it adds it unconditionally. I propose to include the SW_WATCHDOG > > facility by default, but enable it only if there is no hardware watchd= og. > > 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 usefu= l > > at $JOB, and it's annoying to have to build a custom kernel just for t= his > > (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 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 From owner-freebsd-arch@freebsd.org Thu Dec 28 02:23:10 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 BE306E94280 for ; Thu, 28 Dec 2017 02:23:10 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [192.108.105.60]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 9AAFE64394; Thu, 28 Dec 2017 02:23:10 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (bones.soaustin.net [192.108.105.22]) by mail.soaustin.net (Postfix) with ESMTPSA id DFF0F3D0; Wed, 27 Dec 2017 20:23:02 -0600 (CST) Date: Wed, 27 Dec 2017 20:23:01 -0600 From: Mark Linimon To: "Rodney W. Grimes" Cc: karels@freebsd.org, freebsd-arch@freebsd.org Subject: Re: making SW_WATCHDOG dynamic Message-ID: <20171228022301.GA30039@lonesome.com> References: <201712261425.vBQEPMmQ007578@mail.karels.net> <201712271811.vBRIBqOK061996@pdx.rh.CN85.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <201712271811.vBRIBqOK061996@pdx.rh.CN85.dnsmgr.net> User-Agent: Mutt/1.5.23 (2014-03-12) 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 02:23:10 -0000 On Wed, Dec 27, 2017 at 10:11:52AM -0800, Rodney W. Grimes wrote: > 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. By including more things in GENERIC, we expanded our audience past "kernel developers + system administrators". In particular, including "people using desktops and laptops who just want to get work done". Expecting everyone to recompile their kernels would be a shocking step backwards for the project IMVHO. mcl From owner-freebsd-arch@freebsd.org Thu Dec 28 19:17:04 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 356C7EAF104 for ; Thu, 28 Dec 2017 19:17:04 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from vps1.elischer.org (vps1.elischer.org [204.109.63.16]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "vps1.elischer.org", Issuer "CA Cert Signing Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 1BFC5668A5; Thu, 28 Dec 2017 19:17:03 +0000 (UTC) (envelope-from julian@freebsd.org) Received: from Julian-MBP3.local (115-166-0-128.dyn.iinet.net.au [115.166.0.128]) (authenticated bits=0) by vps1.elischer.org (8.15.2/8.15.2) with ESMTPSA id vBSJGuoS005035 (version=TLSv1.2 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Thu, 28 Dec 2017 11:17:01 -0800 (PST) (envelope-from julian@freebsd.org) Subject: Re: RFC: Sendmail deprecation ? To: karels@FreeBSD.org, "freebsd-arch@freebsd.org" References: <201712131321.vBDDL29q039904@mail.karels.net> From: Julian Elischer Message-ID: Date: Fri, 29 Dec 2017 03:16:49 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <201712131321.vBDDL29q039904@mail.karels.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US 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 19:17:04 -0000 On 13/12/17 9:21 pm, Mike Karels wrote: > It is clear that there isn't a consensus on a single choice of MTA, > and that is fine. Here is a summary of my take on current options > after reading the discussion to this point: > > First, we seem to agree that the target for a default setup is not > that of an Internet-facing MTA, which requires some thought and > configuration. Instead, the target is an originate-only system > that does either on-box mail delivery or outbound delivery. At the > very least, it can deliver the sysadmin emails configured by default. > > The options that have been presented: > > o Use dma. That would apparently suffice for some systems, and is already > in base. However, in my opinion, it is missing some capabilities that > some sites (including mine) may require: > - .forward processing > - Its masqerade configuration seems to be too simplistic, e.g. > masquerade all or nothing, rather then exempting root and other > specified system users. > - Some mail clients, e.g. perl packages that we use at $JOB, connect > to localhost:25 (or SMTP on some other host) rather than invoking > "sendmail" directly. dma will not support these. > In addition, it is not as well integrated into the system. It wasn't > immediately obvious to me how to enable it, until I followed the > "See Also" to mailwrapper; I guess I knew that at one time. It also > requires manual configuration of TLS and a certificate if you want to > use TLS. > > o Use the sendmail in base, configured for submission only. This is > completely integrated and works out of the box. It has none of the > limitations listed for dma. IIRC, a certificate is generated automatically > so that TLS could work with no additional configuration. Presumably this > could be done for dma as well, but it has not been done. > > o Use the sendmail in ports. This is apparently more full-featured, but not > as nicely integrated with FreeBSD. No one has volunteered to resolve this > so far. Or maybe it isn't that hard. But it wouldn't work "out of the > box;" the system woudln't have this MTA available until manually installed. > > o Use some other MTA, e.g. OpenSMTPD. Of course there are Postfix, Exim > and probably others, mostly aimed at full-service MTAs. I know little > about these, but they are not pre-configured. (OK, I once configured > an Exim system and got it to do what was required for a test, but I've > blocked it from my mind.) > > Another issue that has been brought up: > > o It's a bother to remove sendmail to replace it with something else if it > is not a package. I don't understand; isn't it just a matter of putting > sendmail_submit_enable="NO" into /etc/rc.conf to be ready to configure > something else? Or are people so short of disk space that they need to > remove the binary, config files, etc? > > It seems to me that the option that is best-integrated, and which serves > the needs of the greatest number of systems, is the sendmail in base. I still > favor a configuration step that selects one of a small number of MTA choices > and configures it, but we don't seem to have a framework for doing that now > if we want something to be working out-of-the box. Thus, I think that > removing sendmail from base now would make the system less flexible and > usable. This is close to my thinking.. I see no real reason to remove it.. the binary isn't exactly huge by today's standards.. -r-xr-sr-x  1 root  smmsp  696880 Aug 24 03:56 sendmail [julian@porridge ~/p4/build_inv_10x]$ ls -l `which vim` -rwxr-xr-x  1 root  wheel  2389560 Aug 11 21:23 /usr/local/bin/vim [julian@porridge ~/p4/build_inv_10x]$ ls -l /lib/libc.so.7 -r--r--r--  1 root  wheel  1654264 Aug 24 03:54 /lib/libc.so.7 Currently  it is the most integrated and I've found it reliable. if it has SSL built in by default we'd be golden. > > 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" > From owner-freebsd-arch@freebsd.org Fri Dec 29 00:54:12 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 69AC5E9E575 for ; Fri, 29 Dec 2017 00:54:12 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from smtp.digiware.nl (smtp.digiware.nl [IPv6:2001:4cb8:90:ffff::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 325727486B; Fri, 29 Dec 2017 00:54:11 +0000 (UTC) (envelope-from wjw@digiware.nl) Received: from router.digiware.nl (localhost.digiware.nl [127.0.0.1]) by smtp.digiware.nl (Postfix) with ESMTP id D9D742E3BF; Fri, 29 Dec 2017 01:53:59 +0100 (CET) X-Virus-Scanned: amavisd-new at digiware.com Received: from smtp.digiware.nl ([127.0.0.1]) by router.digiware.nl (router.digiware.nl [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id pObcvzCd0RJC; Fri, 29 Dec 2017 01:53:59 +0100 (CET) Received: from [192.168.11.152] (unknown [192.168.11.152]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by smtp.digiware.nl (Postfix) with ESMTPSA id 055512E3BD; Fri, 29 Dec 2017 01:53:59 +0100 (CET) Subject: Re: making SW_WATCHDOG dynamic To: Mark Linimon , "Rodney W. Grimes" Cc: freebsd-arch@freebsd.org, karels@freebsd.org References: <201712261425.vBQEPMmQ007578@mail.karels.net> <201712271811.vBRIBqOK061996@pdx.rh.CN85.dnsmgr.net> <20171228022301.GA30039@lonesome.com> From: Willem Jan Withagen Message-ID: Date: Fri, 29 Dec 2017 01:53:59 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.2 MIME-Version: 1.0 In-Reply-To: <20171228022301.GA30039@lonesome.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: nl Content-Transfer-Encoding: 7bit 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: Fri, 29 Dec 2017 00:54:12 -0000 On 28/12/2017 03:23, Mark Linimon wrote: > On Wed, Dec 27, 2017 at 10:11:52AM -0800, Rodney W. Grimes wrote: >> 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. > > By including more things in GENERIC, we expanded our audience past > "kernel developers + system administrators". > > In particular, including "people using desktops and laptops who just > want to get work done". > > Expecting everyone to recompile their kernels would be a shocking > step backwards for the project IMVHO. I've been building custom kernels for as long as I can remember. And it used to be like you describe, get the box running and give it its own build-config. But as the number of systems under my fingers grew, maintenance became more and more a pain/time-consuming. And since about a year I've started using freebsd-update on those systems that need proper maintenance. And I cannot avoid the feeling that this is sort of perpendicular to your suggestion of building custom kernels, since freebsd-update frowns on that... And I've got the feeling that's the tool quite a lot of people use to deal with basic Freebsd maintenance stuff. --WjW From owner-freebsd-arch@freebsd.org Fri Dec 29 22:55:51 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 290E5EB4BFF for ; Fri, 29 Dec 2017 22:55:51 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (smtp.mu.org [IPv6:2001:559:9c:200::ffff]) by mx1.freebsd.org (Postfix) with ESMTP id 190717FB00 for ; Fri, 29 Dec 2017 22:55:51 +0000 (UTC) (envelope-from bright@mu.org) Received: from Alfreds-MBP-2.lan (c-67-169-71-186.hsd1.ca.comcast.net [67.169.71.186]) by elvis.mu.org (Postfix) with ESMTPSA id F11A610C308B for ; Fri, 29 Dec 2017 14:55:50 -0800 (PST) Subject: Re: The future of fortune(6) To: freebsd-arch@freebsd.org References: <5A15DDFA.8060302@Wilcox-Tech.com> <58470.1511396312@kaos.jnpr.net> <20171123074447.GA1834@lonesome.com> From: Alfred Perlstein Message-ID: <8ff1b31f-8fcd-7afa-f14c-387ab71e3671@mu.org> Date: Fri, 29 Dec 2017 14:55:50 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171123074447.GA1834@lonesome.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US 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: Fri, 29 Dec 2017 22:55:51 -0000 On 11/22/17 11:44 PM, Mark Linimon wrote: > On Wed, Nov 22, 2017 at 05:02:21PM -0800, Adrian Chadd wrote: >> but honestly - to me it's a symptom of us growing the fuck up. > This. > > So much this. > > Ten thousand times this. Be careful throwing the last of your childhood toys, one day you will want to give a child a gift and have nothing to give them. -Alfred From owner-freebsd-arch@freebsd.org Fri Dec 29 23:10:04 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 56BC3EB5422 for ; Fri, 29 Dec 2017 23:10:04 +0000 (UTC) (envelope-from bright@mu.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 40DA68015C for ; Fri, 29 Dec 2017 23:10:04 +0000 (UTC) (envelope-from bright@mu.org) Received: by mailman.ysv.freebsd.org (Postfix) id 3C7D2EB5421; Fri, 29 Dec 2017 23:10:04 +0000 (UTC) Delivered-To: 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 3BFB2EB5420 for ; Fri, 29 Dec 2017 23:10:04 +0000 (UTC) (envelope-from bright@mu.org) Received: from elvis.mu.org (smtp.mu.org [IPv6:2001:559:9c:200::ffff]) by mx1.freebsd.org (Postfix) with ESMTP id 28F828015B for ; Fri, 29 Dec 2017 23:10:04 +0000 (UTC) (envelope-from bright@mu.org) Received: from Alfreds-MBP-2.lan (c-67-169-71-186.hsd1.ca.comcast.net [67.169.71.186]) by elvis.mu.org (Postfix) with ESMTPSA id D0D3710C308A; Fri, 29 Dec 2017 15:09:57 -0800 (PST) Subject: Re: bitrot [was: Deprecating / Removing floppy drive support] To: Mark Linimon , "Rodney W. Grimes" Cc: Hans Petter Selasky , Eitan Adler , "freebsd-arch@freebsd.org" References: <43746890-e60a-5c8f-4c77-bbfe9a5a6aa9@selasky.org> <201712031655.vB3GtIME041023@pdx.rh.CN85.dnsmgr.net> <20171203172755.GA4210@lonesome.com> From: Alfred Perlstein Message-ID: <869828cb-e4e2-78fb-84ba-5d0ec8e919b9@mu.org> Date: Fri, 29 Dec 2017 15:09:57 -0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <20171203172755.GA4210@lonesome.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US 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: Fri, 29 Dec 2017 23:10:04 -0000 On 12/3/17 9:27 AM, Mark Linimon wrote: > On Sun, Dec 03, 2017 at 08:55:18AM -0800, Rodney W. Grimes wrote: >> my observation is that FreeBSD is a lot of new toys that work fairly >> well and a collection of rotting bits that get the axe every few >> years. > Having spent 10+ years triaging PRs I can tell you for certain that > there are large parts of the src tree* that no one works on. (For > instance, if we use "bin" as a rough proxy for "userland", there are > 1668 userland PRs.) > > I had a breakdown of kern PRs into "subsystems" which I kept going for > a few years, but it bitrotted (was GNATS-specific). It never really > got any uptake, but I found it educational anyways: > > https://people.freebsd.org/~linimon/studies/prs/prs_for_all_groups.html > > For instance, it led me to believe that large chunks of "libraries" and > "audio" were not actively maintained. > > But beside from features missing from the tools, we have a large, open, > problem with "someone needs to take ownership of the xyz code". > > I would be happy to hear constructive ideas. (Readers should be warned > that based on past experience I no longer believe that "well, someone > should just do that" leads anywhere.) > > obdisclaimer: I am not trying to discourage the people who currently > actively work on maintenance by pointing to the overall numbers; in fact, > I appreciate their efforts. I just want to know how we can clone them. > > mcl > > * The ports tree does a little better by assigning maintainers. It > turns out that most, but not all, of the key components have at least > a putative maintainer listed. It's good but insufficient. > I understand how frustrated folks can be that there are PRs, quite a few with patches, out there that are not being addressed or merged. That said, accessibility is always going to gate contributions and engagement of users. Accessibility can be fixed by a number means: 1) reduce the test / compile cycle. 2) replacing obsolete or seldom used tooling with modern industry standard tooling. 3) lowering the barrier to entry. 4) giving contributors an experience that prepares them for cross functional work. These really are all actually a single point that one should focus on. If a project decides to use a bag of tools that is extremely specific to itself or not widely used anymore it really has only itself to blame for lack of participation of its users.  It is up the project to realize that its infra is lagging behind the industry and work towards bringing it in line with the previous stated accessibility fixes to bring in new and engaged folks interested in work as well as keep its current base of workers interested in continuing to work. -Alfred