I don't know much about acpi, but from the viewpoint of what I know about the atrtc driver, this looks okay. Using rtcin/out_locked() as I mentioned above would be a small performance enhancement. I don't have a ton of free time these days and may not get around to reviewing a revised diff. I'm okay with making the changes I noted above or not; either way is fine with me.

Fix a couple missed number->name changes.

Update comments to explain D_PARTWILD and use D_PARTISGPT instead of 255.

I think this is not a good solution either. It feels like more of the same thing we've been doing for 20 years... finding a small clever hack that makes the current pain go away as an alternative to doing the larger cleanup that begs to be done.

In D19238#411584, @tsoome wrote:

This is insufficient. Whether we like it or not, whether it's documented or not, it is an existing feature that disk_open() with partition set to any negative number means "use the first freebsd-ufs partition in the slice". This isn't documented anywhere, even the loader(8) manpage only says "the syntax for devices is odd". But if we change the current behavior, peoples' existing configurations can break, leaving them without access to a remote system, etc.

This looks good to me (I assume it's been tested, I didn't try it myself).

In D6814#155355, @stevek wrote:

In D6814#155318, @andrew wrote:

This should be attached to the build, and used by the GNU dtc.

I'm wondering should libfdt be conditionally built and, if so, should it be based on MK_FDT and MK_GPL_DTC (since the dtc build will be using it after the suggested changes)?

If using option IPSEC (and I guess GELI and maybe other things) requires explicitly specifying device crypto, then shouldn't this change also cleanup and simplify sys/conf/files to remove "| ipsec | ipsec_support" from all the files that are optional on "crypto"?

This looks okay to me.

In D16507#353355, @gjb wrote:

In D16507#353346, @ian wrote:

As mentioned out-of-band, I added the ntpd UID/GID to work around this issue.

Added it to what? IMO, it's a really bad idea to paper over this mess, it just means we have to suffer all this pain again next time a user is added to the base system.

Sorry for the incomplete statement. Added to the build host so 'installworld' to the target chroot directories did not error.

I could have just upgraded the build host, but chose to apply a band-aid for this one case.

In D16507#353334, @gjb wrote:

In D16507#353295, @royger wrote:

This is part of the 'ftp' target in the release directory that runs the release/scripts/mm-mtree.sh. I see that there are snapshots still being created without issues, so I wonder what runes are used inside of the cluster to generate the install media. Is something different from 'make -C release ftp' used to generate the install sets?

As mentioned out-of-band, I added the ntpd UID/GID to work around this issue.

I'm 'accepting' this revision in the sense that I think this is the right way to achieve unconditional use of users and groups from the source being installed, for the distributeworld target. I can't say whether doing so is a good idea or not in general, because I don't know much about the distributeworld target.

Hrm, I didn't intend for my previous comments to include the "request changes" flag, don't consider my comments to be blocking, I was just throwing them out there to see what other people think.

I'm not sure what led to putting these changes where they're at in the makefile, it seems a bit unrelated to the things immediately surrounding it. It should be noted that for this change to work properly, the new lines must appear before line 833 (pre-patched, or 838 with this patch included). It might make more sense to move this change to just before line 833; that would make it a lot more clear what the real effect of this change is.

In D16396#348104, @cy wrote:

Thanks. You can do ntp and ntp-devel in one commit.

Add PORTREVISION.

Oops, my bad, sorry about that. IMO, you should probably just commit changes like this without slowing down with a phab review.

In D16281#347193, @bjk wrote:

Sorry to have missed this when it first came in; the mdoc could use some changes.

Fix the logic for handling mac(4)-not-in-kernel and mac_ntpd policy not-enabled. The last round of refactoring changed all this stuff to 'early return to run as root' and the logic for these checks got pasted from the old code without change.

Ooops, sorry about that, I guess I never re-tested WITHOUT_LOADER_GELI after making various changes after the first rev.

Add requested logging when moving/changing files and dirs.

Fix a typo (s/driftopt-/driftopt=/) that made it through my initial testing.

While testing and redeveloping the previous version of the rc.d/ntpd changes, I came to the conclusion that automatically setting up a chroot in an rc.d script is complicated and fraught with potential peril. When I got the point of having a embedded awk program that parsed the ntp.conf file so I could figure out whether we needed to mount a devfs inside the chroot for PPS device access, I realized I was way down a too-complicated path.