What are the risks this a avoids?

oh, this is in

commit 4fb507cae916d04fcd1e80e69923c5ca5c4340eb
Author: Warner Losh <imp@FreeBSD.org>
Date:   Mon Feb 9 09:14:16 2026 -0700

(defconst knf-c-style
  '((c-basic-offset . 8)
    (c-comment-only-line-offset . 0)
    (c-offsets-alist . ((statement-block-intro . +)
                        (knr-argdecl-intro . +)
                        (substatement-open . 0)
                        (label . 0)
                        (statement-cont . +)
                        (inline-open . 0)
                        (inexpr-class . 0)
                        (statement-cont . *)
                        (arglist-cont . *)
                        (arglist-cont-nonempty *))))
  "BSD KNF")
(c-add-style "knf" knf-c-style)

is what I use.

This looks good to my eye.
However, in the future, can you please use git-arc to upload patches, or generate the raw diffs with -U99999 please? There's no context to this review making it harder to verify that other paths make this same check.

There's also a onw or places in the tree that climb the tree to find pci

Does this let us take anything out of badfiles.inc?

OK. I'm happy.

looks good, not sure why free vs destroy though

In D53910#1303920, @ziaee wrote:

In D53910#1303914, @imp wrote:

In D53910#1303910, @ziaee wrote:

In D53910#1303904, @jrtc27 wrote:

In D53910#1303893, @ziaee wrote:

In D53910#1303832, @jrtc27 wrote:

In D53910#1303533, @ziaee wrote:

Please understand that I am personally committed to seeing this website refresh land, however I am formally requesting changes proposed over email. I would like to propose the line objected to is replaced with "For over 30 years, this has been a grass roots project carried by passionate volunteers."

Firstly, for those of us not privy to this private email chain, what specifically is being objected to, and why?

The line "Check out the engagement driven by the FreeBSD Foundation on YouTube" is being objected to on the grounds that it is inappropriate for the "Community" box.

A social media presence dedicated to FreeBSD, by people who are involved in FreeBSD, that is an official FreeBSD-related organisation, and is engaging with people on the internet, is inappropriate for the "Community" section of the FreeBSD website how?..

The FreeBSD foundation is it's own entity, with it's own website. The Project is consists of a democratic system, which the Foundation exists completely separate and outside of.

I'd disagree with that characterization if the foundation. It is very much a part of the community and has helped build parts of the community. It's very much not outside of the community.

I did not (nor did i mean to) say that it is not part of the community or has not helped build the community, or even me personally! Rather, the netflix freebsd community is a major part of the community and has helped build it a lot, should that be in the community box? Rather than a statement about the community as a whole?

This is a box labeled "Community" on the front page with 3 sentences. It shouldn't be advertising anything other than the Project's community.

The commit message should explain why...

In D53910#1303910, @ziaee wrote:

In D53910#1303904, @jrtc27 wrote:

In D53910#1303893, @ziaee wrote:

In D53910#1303832, @jrtc27 wrote:

In D53910#1303533, @ziaee wrote:

Please understand that I am personally committed to seeing this website refresh land, however I am formally requesting changes proposed over email. I would like to propose the line objected to is replaced with "For over 30 years, this has been a grass roots project carried by passionate volunteers."

Firstly, for those of us not privy to this private email chain, what specifically is being objected to, and why?

The line "Check out the engagement driven by the FreeBSD Foundation on YouTube" is being objected to on the grounds that it is inappropriate for the "Community" box.

A social media presence dedicated to FreeBSD, by people who are involved in FreeBSD, that is an official FreeBSD-related organisation, and is engaging with people on the internet, is inappropriate for the "Community" section of the FreeBSD website how?..

The FreeBSD foundation is it's own entity, with it's own website. The Project is consists of a democratic system, which the Foundation exists completely separate and outside of.

Just update the phabricator summary

In D56898#1303625, @agh_riseup.net wrote:

In D56898#1303540, @ziaee wrote:

Please add Relnotes: yes to the commit message.

In D56898#1303619, @agh_riseup.net wrote:

In D56898#1303540, @ziaee wrote:

Please add Relnotes: yes to the commit message.

Will do.

Wait, that has to be done when/if the diff is merged to the Tree?

so long as these flags are cool for clang 19 and 20, this is fine.

Nice catch! Thanks!

Thanks!

Looks very straight forward! Thanks for this addition.

+1 on doc too

In D56783#1301197, @emaste wrote:

Yes, via a PR -- https://docs.freebsd.org/en/articles/committers-guide/#ports-exp-run. You can attach a patch to be applied to src (here the patch would include both the parent review and this one). It will get tested in isolation. This sometimes seems excessive and batching a few seemingly trivial changes seems like it would make sense. That said, if there are failures in that hypothetical combined exp-run it may be difficult to figure out what's responsible, especially when there may be a number of already-failing or intermittently flaky ports.

__ is reserved namespace so nothing should fail and I think it's fair if we deem the risk is low enough to not bother with an exp-run.

So the history:

In D46284#1299021, @crest_freebsd_rlwinm.de wrote:

@kevans: Can you think of a realistic situation where someone will have their jail configuration unintentionally executable? I don't think chmod -R 777 /etc is a supported configuration. Are we forced to support FAT32 as root file system on any strange platform or something like that?

This looks great!

bootx64.efi is amd64-specific, so I'm glad you've added the clarifying note!

This looks great! Thanks for updating the docs.

I'm unsure about this novel dance with F_GETFL. I've not seen this in any of the other init programs I've looked at (admittedly, they were Linux or older BSDs), so I'd be curious to understand the reasoning behind that vs doing the simpler code I left in the specific comment.

Now that lead me down the rabbit hole.
boot2 doesn't do this in boot2.c. It calls lookup() which is in ufsread.c in libsa. And that has this loop to parse the path (path is a cursor variable that walks through the path, s is the end of this segment of the path):

        for (;;) {
                if (*path == '/')
                        path++;
...
                for (s = path; *s && *s != '/'; s++);
...
                ls = *path == '?' && n == 1 && !*s;
...
                if ((dt = fsfind(name, &ino)) <= 0)
                        break;
                path = s;
        }

n == 1 means that ? is the only character (ignoring degenerate cases) after the / and is the last character of the string. So ? or /bin/? or /usr/local/lib/? will trigger ls == true. fsfind checks the global variable 'ls' and will just print all the files in that directory and return 0 so this loop terminates.

This is great. And it looks like there's more wired up than just -z for apm.

And to answer your other question: only suspend works

In D56629#1296825, @ivy wrote:

are you sure? /usr/sbin/zzz appears to be a shell script that controls ACPI via acpiconf(8), and only falls back to using apm(8) if the machdep.apm_suspend_delay sysctl exists, which it doesn't on my machine; i assume this comes from apm(4).

are there other functions of apm(8) that work on ACPI systems?

Apm, the program, works on any acpi machine. It's what is installed as zzz and still works. Apmd only talks to APM BIOS machines which are 20years dead at this point. Apm, the program, calls a generic interface for sleeping...

review from chuck

Oh that's fun

rebase and maybe push the fixes that mmel wanted

OK. Updated a while ago...

oh! Yea, this is wrong. The return type may be wrong for things like lseek, but this isn't how to fix it.

In D56621#1296656, @jrtc27 wrote:

And indeed we do already handle the newline case correctly:

$ printf 'foo\nbar\nbaz\n' | sed -n $'/foo/{s/foo/bar/;p\n}'
bar

In D56621#1296655, @jrtc27 wrote:

Not sure if this is actually a bug. POSIX says:

The <right-brace> shall be preceded by a <newline> or <semicolon> (before any optional <blank> characters preceding the <right-brace>).

So I think this is more a case of "be helpful and do what you clearly meant" rather than "oops we weren't conforming"?

In D56621#1296627, @bdrewery wrote:

Can we get a test added for this?