The implementation of the progress bar is simple, but duplicated for
most minidump implementations (32-bit ARM being the exception). Extract
the common bits to kern_dump.c. Ensure that the bar is reset with each
subsequent dump; this was only done on some platforms previously.
Details
Details
- Reviewers
markj manu - Group Reviewers
ARM - Commits
- rGfc7febf483a4: minidump: De-duplicate the progress bar
rGab4ed843a303: minidump: De-duplicate the progress bar
Diff Detail
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
Comment Actions
I wonder if you could go further, by making the MI routines responsible for initializing and managing delta. That is, on every write just pass the number of bytes written and let minidumpsys_pb_progress() decide whether to print something. In other words, I wonder if we can avoid having to maintain both delta and counter in each minidumpsys() implementation. But I'm fine with this as-is.
| sys/sys/kerneldump.h | ||
|---|---|---|
| 160 | Is there any reason these are specific to minidumps? It looks like they should just share the dumpsys_ namespace. | |
Comment Actions
Rename functions to have a dumpsys_ prefix.
Push the counter logic into the progress bar.
Add missing changes to i386 minidump code.
| sys/sys/kerneldump.h | ||
|---|---|---|
| 160 | There was not. In fact, I wonder if this progress bar could be used for full dumps as well... | |
| sys/x86/include/dump.h | ||
| 46 | So I've added this definition to each arch's dump.h, so that the existing behaviour is preserved. I'll note that for a small VM, this value is a little large for x86: db> dump Dumping 98 out of 473 MB:..17%..33%..49%..65%..82%..98% Dump complete I think the ideal method might be to scale this parameter based on the total size of memory. | |
| sys/x86/include/dump.h | ||
|---|---|---|
| 46 | It would be cool if we could report progress in response to ctrl-T. :) | |