Date: Mon, 12 Oct 2020 02:13:24 +0000 From: Alexey Dokuchaev <danfe@freebsd.org> To: Warner Losh <imp@bsdimp.com> Cc: Kyle Evans <kevans@freebsd.org>, Toomas Soome <tsoome@me.com>, src-committers <src-committers@freebsd.org>, svn-src-all <svn-src-all@freebsd.org>, svn-src-head <svn-src-head@freebsd.org> Subject: Re: svn commit: r366626 - head/sbin/reboot Message-ID: <20201012021324.GA38670@FreeBSD.org> In-Reply-To: <CANCZdfpL0ajtSjFYj-5p3Si_vsV-4Q_qHkNY8oaVDsZ%2BZwQcLg@mail.gmail.com> 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> <CACNAnaH%2BocNxvkXiiqa_13RRf5oT9O0jTjik2gw_83WHStXTeA@mail.gmail.com> <CANCZdfpL0ajtSjFYj-5p3Si_vsV-4Q_qHkNY8oaVDsZ%2BZwQcLg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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? > 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? > 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"<space> 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. > 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? > 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. ./danfe
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20201012021324.GA38670>