Yes. I agree. It will be defined for both kernel and loader builds.

There's almost no difference between sync; shutdown and just shutdow other than more typing. The latter does a sync first thing anyway (in the system call) so you may start the io a smidgen earlier with the former... but sync doesn't guarantee the io will be done before shutdown starts... so even doing them on sepatate lines might only gain you the time it takes you to type shutdown at the expense of typing 5 extra characters.

Since reboot and shutdown system calls were added just after v7, the sync 3 times dance is a placebo. It was marginally useful on v7 before powering off. It's existed in lore as being necessary when it hasn't been. And since all it does is schedule IO you can't use it to know data is on the disk.

update per Chuck's idea of making it clear it's an index. Hopefully this makes
it clearer. Thanks Chuck!

So I'm not saying we need it now, but we likely need to know if we can... get some sleep

I don't suppose that yhese could be generated automatically? It's a huge table to maintain by hand...

Any reason to not always set cn_unmute = 0 unconditionally?

In D43463#1024283, @delphij wrote:

Can we merge this?

I'd thought we didn't need to propogate the locale, since both strerror and strerror_r use the same locale()... but I'd forgotten printf can have a different one, so I proposed something different in the bug.
We could share buf and errormsg, but maybe it's not worth the hassle.

this looks good to me now (forget about my other comments... I clicked some something weird maybe?)

I think a rebase is in order... this diff is picking up a lot of "noise" that have nothing to do with fortify....

So which events and why? I dont think the appraoch outlined here can possibly work.

impressive gains if true... However, the 'no-whole-archive' stuff makes me ask the question "doesn't that eliminate all the commands that we build on linker sets?"

The code likely is good, but the why for some of it isn't obvious to me and needs some clarification I think.

Might want to also note that you've made a lot of variables local. I think that's a good change too, but best to note it or split it off into another commit.

I think this is good... but mav will know for sure if we're missing something

Surprised this wasn't already the case

I've created a hash module that has some of the sha routines. I don't have big issues connecting those.

In D44706#1021491, @jhb wrote:

In D44706#1020670, @imp wrote:

One nit... also applies to all of this series of reviews: consider omitting the license boilerplate.

Hmm, are we ready to do that? I know we have some SPDX-only files in the tree and are kind of allowing it, but I wasn't sure we'd crossed the point to preferring that by default.

I'd be happy moving to #pragma once for almost all files in the tree...

oh! That's the problem... I did a clean build and that's why I didn't see it...