Looks good. Must have missed these bits when we upstreamed it.

If you moved lfs.[ch] to libexec/flua/modules, then a simple -I addition to CFLAGS and a .PATH would get the job done.

I don't like the lfs.h sharing detail, but it's fine enough we can work out after commit.

I'm cool with the sysctl/tunable naming.. Don't know about TAA enough to comment on the rest :)

In D22147#489200, @brooks wrote:

I think this is ready to go as is. PLIST cleanups can wait IMO.

Seems sane to me, but I'd feel better about getting it committed if others more deeply familiar with the aslr stuff give it their blessing.

This looks like a simple bug fix to me, so I'm inclined to let it in.

I love it now.

Hmmm, does this break native builds for gcc?

I think what we're seeing is that we're running this with the queue unfrozen. This sometimes leads to the race I found because, I think, we run things twice: once in the ccb release path, and then again in the schedule path. The freezes and single stepping has always confused me. Part of the confusion is why we only see this sometimes... How does that come to be... The other is why does setting the state *SEEM* to fix this issue, because we should see double entry into the PROBERC state, rather than re-entry into the PROBEWC. I suspect this just never matter before the write-protect probing code was added since we always exited from PROBERC, race or no and there was no chance to actually race due to the DA_FLAGS_PROBED short-circuiting.

I add Scott long to reviewers

In D20261#487283, @emaste wrote:

I would definitely get this in even if we have to leave ld.bfd for 32-bit powerpc initially.

In D22271#487273, @vangyzen wrote:

It would be nice to include some documentation. The systemd man page seems most useful and canonical, but it's LGPL. Maybe include a link to it in a comment in the generated file?

Now with freshly-written man page.

More review commentary addressed.

In D22249#487261, @allanjude wrote:

Maybe give Warner a chance to provide any more feedback before we commit this.

In D22271#487097, @manu wrote:

Does that needs a exp-run too ?
I guess that some ports currently test if this file exists at configure step and don't depend on the current port so this might affect them.

Update per review comments
Update etc/defaults/rc.conf

Also standard in Solaris, per bcran:

For those that are interested, the DragonFly commit is here http://gitweb.dragonflybsd.org/dragonfly.git/commit/9c172c374855a49366c18d9b34b978ce87a7fa2b

In D22271#487162, @manu wrote:

Thanks. So I guess that my next question is : how does this files affects those program ?
It is just cosmetic ? (like they will display FreeBSD instead of the default "Linux" string) or something else ?

In D22271#487094, @bapt wrote:

To be clear, I am validating the content of the file and the principle of a rc.d. Now I am wondering it is won't be better served by a port/package as it has a niche usage anyway (for now at least), and that will make it cover all supported version of FreeBSD straight away.

It will still be possible to move it to base later if we have a real need for it in base in the future

I'm not aware of it being checked at configure stage by anything -- if this were the case however, it would be even more important for it to be in base :)

update per cem and brooks

In D22144#484174, @bdrewery wrote:

In D22144#484006, @jhb wrote:

I guess the extra directories don't hurt. I'm less certain about the implications of the missing checks for an empty KERNBUILDDIR.

Same concerns but I like the change otherwise.

These look good to me.
Thanks for integrating my feedback.

In D22249#486854, @chuck wrote:

In D22249#486852, @trasz wrote:

I have the same problem - the most factually correct way would be "newbus parent node", but that would be completely unparseable to most of the users.

Any thoughts on merging those two attributes into a single string? I've mimicked the fields from struct ccb_pathinq, but I'm not sure if that's the right thing to do.

I'm struggling with this as well. How does "Controller" or perhaps "Drive controller" strike you? With the end result being something like "Controller device name" or "Controller device path". Open to suggestions.

Nothing caught my eye, though the PLIST is getting to be rather long and a bit of a PITA to deal with :(

It would be better to put

#define EXIT_CANCELED 125

and use that instead of the bare 125. I know we have other numbers elsewhere, but that's a good place to make this not a magic number.

teemo. Coding the ansi escape sequences is really a bad idea.

OK. This compiles for me. This runs for me. I get funky characters on my serial console for the menu, though. I can't recall if that used to be the case or not.

In D22212#485397, @cem wrote:

Anyway: I'm not keen on this kind of CHERI patch that just shuffles code around for CHERI's convenience with non-improvement or negative impact to FreeBSD.

I don't see anything wrong. the discussion that bdrewery and I were having was that there may be a more optimal way.

There's likely others, but I've not grepped them up yet.

/*
  * Fill in the devid, now that we've labeled the disk.
  */
 (void) snprintf(buf, sizeof (buf), "%ss%d", path, slice);
 if ((fd = open(buf, O_RDONLY)) < 0) {
         (void) fprintf(stderr,
             gettext("cannot open '%s': %s\n"),
             buf, strerror(errno));
         return (-1);
 }

is one example, this one is from cddl/contrib/opensolaris/cmd/zpool/zpool_vdev.c

In D22193#485068, @trasz wrote:

In D22193#485062, @imp wrote:

There are lots of places in the system that will break when this is not '' . What are your plans on fixing those?

It’s empty by default; if user needs it I suppose it’s their responsibility to update paths in eg fstab. Or do you mean there are some scripts/binaries that hardcode it?

There are lots of places in the system that will break when this is not '' . What are your plans on fixing those?

This looks good to me...
I'm unsure that we need both the intel-pcm and intel-pcm-devel ports... There's not a huge need for multiple versions and the could be merged (and I'd be happy to cede control to egypcio@)

In D20562#484092, @tsoome wrote:

In D20562#484088, @danfe wrote:

@tsoome wrote:

Hope this helps.

It does, thanks! However, I'm still not sure if I need to create startup.nsh or not. Quick googling suggests that one might get boot problems in some environments if this file is missing. Wiki page does not mention it.

Yes it is situational, I have never needed it myself.

https://reviews.freebsd.org/D22144
is what I'm thinking. I think I have all the dirs in this one and found all the places we use it.
I've not test tested all the use cases....
so we can work out the sharing issues there.

In D22139#483929, @tsoome wrote:

In D22139#483902, @imp wrote:

I'll take a look at this... It looks OK.

But, the "port" changes from the I/O port to the UID if I'm reading things right, which is effectively a random number (on a machine it's stable, but it varies from machine to machine)

Are you sure it is random?, because we found out the handle order is not fixed and acpi uid seems to give better results - haven't heard unexpected port order so far.

I'll take a look at this... It looks OK.

This looks correct.
I agree with the IRC comment about a kassert in uma_zalloc for the flags, but that's not needed here.

Looks good to me. It's one of the two ways that I saw to fix it, and this is likely faster than the other way (pass the limit to vspace()).