The motivation here is for future changes to the coredump code to be able to
build up a coredump into a shmfd instead of a vnode, which then gets tapped
out to userland via a character device. This also opens up the possibility
that it's useful for the kernel to be able to construct a shmfd and pass it
out to a process that shouldn't need to write to it.
Details
Diff Detail
- Repository
- rG FreeBSD src repository
- Lint
Lint Not Applicable - Unit
Tests Not Applicable
Event Timeline
I do this here, specifically: https://git.kevans.dev/kevans/ucored/src/branch/wip/kmod/kmod/coredump_ucored.c#L117
That shmfd is populated down in the coredumper it installs. I suspect I'm going to play with the interface a little bit as far as how userspace actually receives these new fds, but I don't anticipate much change in the parts relevant to this review. My current plan is to try and get the interfaces I need into 15.0 (this stack of 3 is sufficient), then iterate on it a bit in ports. I think ucored(8) and the associated kmod would eventually be a good addition to consider for base as it'll add significant flexibility to what one can do with these things (to include piping them to some command, which is native functionality to a Linux kernel but more complicated than I care to implement).