svn commit: r366626 - head/sbin/reboot

Warner Losh imp at bsdimp.com
Mon Oct 12 03:17:55 UTC 2020


On Sun, Oct 11, 2020, 8:13 PM Alexey Dokuchaev <danfe at freebsd.org> 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"<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.
>

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

>


More information about the svn-src-head mailing list