From owner-svn-src-all@freebsd.org Mon Oct 12 03:17:56 2020 Return-Path: Delivered-To: svn-src-all@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4E4E242AD3E for ; Mon, 12 Oct 2020 03:17:56 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-qt1-x841.google.com (mail-qt1-x841.google.com [IPv6:2607:f8b0:4864:20::841]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4C8kQC3Y3Cz4qHx for ; Mon, 12 Oct 2020 03:17:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-qt1-x841.google.com with SMTP id a9so12657304qto.11 for ; Sun, 11 Oct 2020 20:17:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b/Wvc/KzItEiT3eqpeX702qP3vVp/qHCLecBcJRS/3M=; b=oqag8xmsyfIvOkUuYBnrVWDtBn4/ZSIXA3yNdasT62j9/NwqD9F4wocXeOH6H+f2pw H1iMPn9dV7qsmQvUcypr9qAR9gEOkfIXkGsLaRnqIWfoLkInM0+vFV5szUo66kIlxSth +hdZeE0ASosUiqlAtLseB5wjsEAt6BKZGoIZyRodTKVdqrjusKw1jk8ZuHD3lc7w4z9D 5KWSGsL1pOTSnakqco8vqhozXy5yk2qKXaivvvs7aw23npQwHjM3UsY3zZr1CtfJyivt xPboioh0gHqQiDRUH9B6pTc/p6KMyFRvfE+deww80qC5wA+ZHu/f/3l4CT9L0zIxBZxp PUYA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b/Wvc/KzItEiT3eqpeX702qP3vVp/qHCLecBcJRS/3M=; b=HT5VUGiZ7O/AYU1Cs2rCwmjrBCXaepHdu6AaZv1eeXM9afnKFxnJ1aVSGB8LI9ROLM OowZ9Bd5INd1hkCRcipE+DbD60Lme2YKWRYjuSGdY/LjGI6kQMMCnLL8VwENFQeEdhGF naKL5hSMkuDVkC2uvHtEFXaTzqYIADbmUEYg0IQM9BSBO7wlprvXFoJNmZMCH5gndKiV D1DQNrOPR8BnLcXUm/KpIr5TBte6lkwwtfbJgISb8yLeIWsXheRI31ozVh4V8Z7Otivk XBkz/K/TAMoCTd8qVeRSBluqungiY6mwmC4N9JSXhWE8dz4ZmepGV/3lrDe6KwEPEUcd T2Ig== X-Gm-Message-State: AOAM531SSkHsoH6uISXht1hI6pYkP5upARx8i+aqmafp4ne8GsDG5Gaa M0NjzJFXYwul4vS4YiNUuHqRX9pdtvliVVEIDDMExw== X-Google-Smtp-Source: ABdhPJxrlPgA2Uqa82AL6nDuvxNRxqmuCQ1uljyezAGoS1TlUyaMZCai5ThH7XQtkPcdr5+HYdT+wUdpHtqt/5a4Px0= X-Received: by 2002:ac8:3178:: with SMTP id h53mr8184814qtb.187.1602472673558; Sun, 11 Oct 2020 20:17:53 -0700 (PDT) MIME-Version: 1.0 References: <202010111040.09BAeCfg073782@repo.freebsd.org> <8601CC07-3A43-461A-915C-3CB68BADF41A@me.com> <20201011130151.GA32755@FreeBSD.org> <35355AD6-42C6-48A2-8FCF-A371A82D683A@me.com> <20201011133023.GA67893@FreeBSD.org> <20201012021324.GA38670@FreeBSD.org> In-Reply-To: <20201012021324.GA38670@FreeBSD.org> From: Warner Losh Date: Sun, 11 Oct 2020 21:17:42 -0600 Message-ID: Subject: Re: svn commit: r366626 - head/sbin/reboot To: Alexey Dokuchaev Cc: Kyle Evans , Toomas Soome , src-committers , svn-src-all , svn-src-head X-Rspamd-Queue-Id: 4C8kQC3Y3Cz4qHx X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20150623.gappssmtp.com header.s=20150623 header.b=oqag8xms; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::841) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.55 / 15.00]; RCVD_TLS_ALL(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20150623.gappssmtp.com:s=20150623]; NEURAL_HAM_MEDIUM(-1.01)[-1.007]; FROM_HAS_DN(0.00)[]; RCVD_COUNT_TWO(0.00)[2]; NEURAL_HAM_LONG(-1.01)[-1.008]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[svn-src-all@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; RCPT_COUNT_FIVE(0.00)[6]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20150623.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.54)[-0.537]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::841:from]; R_SPF_NA(0.00)[no SPF record]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; MAILMAN_DEST(0.00)[svn-src-all]; FREEMAIL_CC(0.00)[freebsd.org,me.com] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: svn-src-all@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: "SVN commit messages for the entire src tree \(except for " user" and " projects" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 12 Oct 2020 03:17:56 -0000 On Sun, Oct 11, 2020, 8:13 PM Alexey Dokuchaev wrote: > On Sun, Oct 11, 2020 at 09:12:43AM -0600, Warner Losh wrote: > > ... > > There were cases that were discussed when the feature went in that > > required it to be removed in some failure modes for full functionality. > > I don't recall if they were in the rc thread or somewhere else. > > You mean, literally delete the file, that is, nextboot_enable="NO" can > not be enough? > Yes. Sometimes it's not reliably written in some failure scenarios. In those cases it must be deleted. > And honestly, nextboot.conf is special in so many ways. We have no > > unlink in the loader for UFS and no write for ZFS or MSDOS. In those > > What's the problem with in-place overwrite in the FAT case? > Last I checked, it wasn't implemented. It could be done, but hasn't been. > cases, the rm from rc is what you want > > I still don't understand how could rm be better than graceful disabling > alternative configuration with nextboot_enable="NO". I most certainly > do *not* like when my custom config files are being removed, especially > silently. When I see nextboot_enable="NO" I know that the file > had been processed, and processed by the machine, not me (since I would > never add trailing space). When I don't see the file, I'd be questioning > myself if I've ever added it here, or maybe I put in the wrong location. > Nextboot.conf is special. It will be deleted. It doesn't belong to you, it belongs to nextboot(8). > I'm not likely to remove it, but if UFS grows unlink in the future, > > this man page will need to change. > > Just because it's easier to implemented unlink for UFS then (over)write > for ZFS? > Both are hard in ZFS. Unlink has issues that I hadn't recalled, so that path is unlikely... > Then again, all the loser [loader?] man pages need a complete rewrite, > > or close to it. > > Personally I find them quite useful, except when they contradict the > reality (like this time). In these cases, I'd fix them. > For now, it's fine. Warner >