From nobody Sat Jun 4 07:18:18 2022 X-Original-To: doc@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 3672E1B4641E for ; Sat, 4 Jun 2022 07:18:28 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4LFWLq3kG2z3C2c; Sat, 4 Jun 2022 07:18:27 +0000 (UTC) (envelope-from bz@FreeBSD.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1654327107; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=DuKK/73eybS/0kuPKl+BFvlpaXEhgQ8bUx8Xy2vXTFI=; b=oW8jvAMHVsHulLxDggrxl+MFm2kjYhq9hdzvtpyQmgAEHjhycEcGlPNQ2VY35a5NLgrh9O t7HmxD6dUVvk5Tr3ZPhQIWKhARNb9HrO5AwYxNwoG08QX6J/vY2RVd4415f5PR8w4S3htZ Xn9cGKud3EGuvTrS2KHtMBmWNKS0jFSxiLZOHOXp51NrkZxxLVHlmjuwxZGET8Twmwspst Y/SLkN8bWjVFXSMkISxq95JuDBUVxnU3Jxp2fVwwhuMBwHeWPAegBENZt+oRY6GZBZKCad OKkaKWzaQOPcgNPrLyac/DQGKYZLYBkMMRelWoP7Iq+JjU/Q6slEr+nM9EP7Xg== Received: from mx1.sbone.de (cross.sbone.de [195.201.62.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mx1.sbone.de", Issuer "SBone.DE" (not verified)) (Authenticated sender: bz/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 949D5BFA4; Sat, 4 Jun 2022 07:18:25 +0000 (UTC) (envelope-from bz@FreeBSD.org) Received: from mail.sbone.de (mail.sbone.de [IPv6:fde9:577b:c1a9:31::2013:587]) (using TLSv1 with cipher ADH-CAMELLIA256-SHA (256/256 bits)) (No client certificate requested) by mx1.sbone.de (Postfix) with ESMTPS id 174088D4A2E4; Sat, 4 Jun 2022 07:18:22 +0000 (UTC) Received: from content-filter.sbone.de (content-filter.sbone.de [IPv6:fde9:577b:c1a9:31::2013:2742]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPS id 9C1A8E707CF; Sat, 4 Jun 2022 07:18:21 +0000 (UTC) X-Virus-Scanned: amavisd-new at sbone.de Received: from mail.sbone.de ([IPv6:fde9:577b:c1a9:31::2013:587]) by content-filter.sbone.de (content-filter.sbone.de [fde9:577b:c1a9:31::2013:2742]) (amavisd-new, port 10024) with ESMTP id y2btJmn0hWVu; Sat, 4 Jun 2022 07:18:19 +0000 (UTC) Received: from nv.sbone.de (nv.sbone.de [IPv6:fde9:577b:c1a9:31::2013:138]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mail.sbone.de (Postfix) with ESMTPSA id 723BFE707AE; Sat, 4 Jun 2022 07:18:19 +0000 (UTC) Date: Sat, 4 Jun 2022 07:18:18 +0000 (UTC) From: "Bjoern A. Zeeb" To: Pau Amma cc: Doc Subject: Re: Revisiting the section 4 manual pages loader.conf boilerplate language? In-Reply-To: <95c6f79ad1950273013b14ae995d1c1a@gundo.com> Message-ID: References: <95c6f79ad1950273013b14ae995d1c1a@gundo.com> X-OpenPGP-Key-Id: 0x14003F198FEFA3E77207EE8D2B58B8F83CCF1842 List-Id: Documentation project List-Archive: https://lists.freebsd.org/archives/freebsd-doc List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-doc@freebsd.org MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1654327107; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=DuKK/73eybS/0kuPKl+BFvlpaXEhgQ8bUx8Xy2vXTFI=; b=KjsaAWcun7Xx8prXUup27LlV5qxKyErDxMxPq6xEghT1cx7DG/wA3tsKgt4ifgVtcHqz0f BQnaBAqiyf9oU222kagf+HrwsvKQnqTvfagUbEFKnm0hJjmubaHR4ojrD9FlA1GxLtBJCW mclCH7eoN5XFYhvzVyuQBw5AbizVVcetocS8tuOuf9QBKbUVoeyqcdq4nTV9IAhn8swr1c Gus/yhnuj+jYzh+V5KPAlEGXVf3NgFcVBI8CbU+6rwq1pNS0OhFWuxoM/MajTBDPdHTHoe Aq/ZRzRMzuxDP6IONhJwkaWUPLxLr/FMOW9EF+ZH2JUCYpwH+HRenLk61iqkyQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1654327107; a=rsa-sha256; cv=none; b=qOKJZtadepO1tMFLY8sqkCjVFjIWy/eCJG4UJF4/CTmI9hfJb1OYtB4FwABva6rKMhxISf 1A91ECMks9Gg2yeNvDV8Y4OyOu0Sbw34pNDwQxKI3Lhc5TMU2E8I5/TdMCyE9dID5QB9ZU xtBeWuyMI8TeEb5fMdkVGlgaicSSVcHEWartu8QPKix3SXCXAn8UFnEHhXgXORfqMtvDnK c69Ev+GDSWFpaADA1Yag8pXGfVI3G9Dqo48Q17t5r/8BC527Ej6KArjZ2KXgAtwOY0VUu3 MDDe04r/lFisLGkBuljdbepYVqZaCBEbZBTH7458MlailKfPSFKcVGolhAITiQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N On Fri, 3 Jun 2022, Pau Amma wrote: Hi, > Currently, 3 section 4 manual pages say to use kld_list in rc.conf for > loading: acpi_video(4), iwlwifi(4), and rtw88(4). Contrasting this with 367 > following share/examples/mdoc/example.4's lead and instructing to use > loader(8)-time loading, the current approach appears to be: loader(8)-time > unless it needs rc(8)-time loading (explicitly discouraged for iwlwifi(4) and > rtw88(4), which say to rely on devmatch(8) if at all possible). However, this > may not be the best idea, considering: > > rc.conf(5): > > kld_list (str) A list of kernel modules to load right after the local > disks are mounted. Loading modules at this point in the > boot > process is much faster than doing it via /boot/loader.conf > for those modules not necessary for mounting local disk. > > devmatch(8) itself, as already mentioned, which aims to make explicit loading > (either way) unnecessary in most cases; > > several Freenode^WLibera #freebsd discussions, in at least one of which > kevans stated that rc(8) loading was much safer, especially for large modules > or drivers. What was the cause for that assumption? I assume that both just run kldload. > So I think the default suggestion should be changed from loader.conf to > rc.conf, or maybe to; devmatch preferred, or rc.conf if not an option. > > Thoughts? The problem is more tricky. Not all drivers do provide data for devmatch to work yet. Also some drivers do want to be loaded from loader and not later as they might be essential for booting to multi-user. I am generally tempted to remove the boiler plate from almost all man pages (once the driver supports devmatch) and have a separate man page to point at for how (many ways) to load a driver, possibly along (if it needs special requirements) a suggested hint of which way to use. In other words: unless the driver has special requirements add an .Xr at the bottom to See Also which points at a (new) man page and be done. Why? My understanding is that most of this is part of an effort started but never fully finished to (a) make GENERIC minial -- everything you may not need to boot to multi-user should be loadable by devmatch or kld_list (the latter mostly being there for non-devmatch supported drivers these days or a driver having special requirements) and (b) to give the user a seemless experience where drivers for components supported would just show up without any configuration (hence preference of devmatch vs. kld_list). (c) Lastly there are cases when modules cannot be loaded anymore after loader (or in case of kernels without module support). This is often used for netbooting or with / on a memory disk or in security environments. But also (vendor) strage drivers were examples as you want to be able to access the disks holding your base system. Based on this I started to discourage loader loading and after having devmatch support also kld_list usage in the man pages for iwlwifi and rtw88. Just my 0.5ct /bz -- Bjoern A. Zeeb r15:7