It looks like Phabricator will report that there are property changes on the directory but does not show the details - you can confirm that svn diff shows this metadata change:

I believe that you should allocate a flag in the feature note and use it to opt-out (or opt-in ?) of max_prot.

I think @ota_j.email.ne.jp started working on patches before you removed these ports from the tree.

There's random bits of boot1.efifat lore scattered around, e.g. Google turned up https://ashish.blog/2018/06/freebsd-uefi-boot/ and https://gist.github.com/tehpeh/a5676b711db94f6c1b9af1ec3356a13c. Hopefully a relnotes entry and a mailing-list heads-up is sufficiently discoverable by authors of those sorts of docs.

I approve, this should go.

Perhaps we should put a comment at the beginning of this file explaining that it's not a perfect match for style(9) and providing an example or two of how it can be used?

Tested on X86? I had an earlier version of this in my WIP tree for testing on eMAG/ThunderX2 (where it worked) but encountered a panic on x86. I do have some other WIP in that tree though.

Address issues reported by markj

The previous implementation does suffix matching, which libelftc does not. However, I think this is fine; in general it is unlikely that one section's name is a suffix of another. For .strtab we'd want to do suffix matching.

By inspection existing elf_getscn mirrors the logic of the existing while loop here

sys/tree.h works on all supported operating systems? (for upstreaming)

Committed as rS348628, forgot review tag.

LGTM

Submitted by: @ali_mashtizadeh.com
Relnotes: Yes
Event: Waterloo Hackathon 2019

I will commit the uname changes separately

No objection but I'm generally not a fan of the deferred evaluation; what about just setting include_metadata=yes/no/if-modified and making the test something like
if [${include_metadata} = yes || (${include_metadata} = if-modified && ${modified} = yes)]

In D20479#442068, @ota_j.email.ne.jp wrote:

What do you mean by "an exp-run?" I had made buildworld and buildkernel successful on i386. Universe will be better but I don't have enough disk space.

Original PR suggest visit and fix all of ports. It's been over 20 years since taken out of POSIX mentioned PR, I hope most of ports are sys/dir.h clean.

Should request an exp-run for completeness sake.

In D20475#441968, @emaste wrote:

presumably you want to compare readelf -t too :)

elftoolchain readelf and binutils readelf produce identical formating for readelf -St /lib/libc.so.7.

presumably you want to compare readelf -t too :)

In a fork based on our svn2git mirror (i.e., based on https://github.com/freebsd/freebsd master branch) this will produce a version number like: r348309+937a4a817304-c260384(wipbsd.20190326)-dirty. We'd generate e.g. r348309=937a4a817304-c360384(test) in a git svn-based fork.

Ok, LGTM; I'm not an expert on man page markup but can be adjusted after commit if needed.

The very first version had:

f3()
{
					/* Empty line if no variables. */
	return (1);
}

LGTM

LGTM

Can you provide a link to the original source file, and make a second review (or link to a diff) that shows the delta between upstream and your ported version?

Of course this will need to go upstream as well.

please just commit with the baudrate 0 comment preserved

Do we currently have changes relative to upstream in any of the files affected by this review? (Knowing there are none, or what they are, may be useful in the future when we import 9.0.)

All known outstanding issues are recorded as parents of this review?

LGTM although I am curious how _dwarf_get_reloc_type actually gets used?

That same kernel did not boot on ThunderX2

Tested on Ampere eMAG (along with WIP I brought over from @manu).

@ota_j.email.ne.jp will you update/address the open questions?

I will pick up whitespace cleanup, .Dd bump etc. for commit

At the 2019 Waterloo Hackathon @markj offered to try to take a look

CC folks either in IRC discussion or in person at Waterloo Hackathon 2019

In D20326#438264, @ali_mashtizadeh.com wrote:

Sample output:
root@skylake8:~ # uname -a
FreeBSD skylake8.rcs.uwaterloo.ca 13.0-CURRENT FreeBSD 13.0-CURRENT #9 da147860ca7(master)-dirty: Mon May 20 17:32:20 EDT 2019 ali@strange.rcs.uwaterloo.ca:/build/ali/obj/working/freebsd-dev/amd64.amd64/sys/GENERIC amd64 42e907d740dd9560a2dfd7187eee20e41e9fbd9f

In D18291#438263, @arichardson wrote:

In D18291#438254, @jhb wrote:

I'm pretty sure we use 4byte alignment (.balign 4) to ensure its aligned to one instruction.

From the gas manual,

The way the required alignment is specified varies from system to system. For the a29k, hppa, m86k, m88k, w65, sparc, and Hitachi SH, and i386 using ELF format, the first expression is the alignment request in bytes. For example `.align 8' advances the location counter until it is a multiple of 8. If the location counter is already a multiple of 8, no change is needed.

For other systems, including the i386 using a.out format, it is the number of low-order zero bits the location counter must have after advancement. For example `.align 3' advances the location counter until it a multiple of 8. If the location counter is already a multiple of 8, no change is needed.

will also want a uname.3 update

Do we not just mount another devfs at compat/linux/dev in some cases?

Functions which create/initialise a Q number.

I like this.