https://cgit.freebsd.org/src/commit/?id=2cb49090114108d594195b9b32c762391340484c
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Wed, May 1
Tue, Apr 30
Mon, Apr 29
Sun, Apr 28
In D33233#1025516, @olce wrote:In D33233#1025445, @imp wrote: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.
The main difference is that you control the time you leave to the system to actually write to disk. Typing sync and then shutdown almost immediately indeed doesn't make much sense. Waiting for some seconds or much more does, if you know statistically that all writes will have finished by that chosen time.
Sat, Apr 27
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.
Fri, Apr 26
Thu, Apr 25
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?
Wed, Apr 24
In D43463#1024283, @delphij wrote:Can we merge this?
Tue, Apr 23
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.
Apr 23 2024
Apr 22 2024
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....
Apr 21 2024
Apr 20 2024
So which events and why? I dont think the appraoch outlined here can possibly work.
Apr 19 2024
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?"