On 2026-07-31, John Ogness <[email protected]> wrote: > Is that really a problem? The code would be much simpler and easier to > review and verify if you did it this way. > > At least, I would expect a patch that does this implementation > conversion first. Then, if you really need the caching optimiziation, a > second patch that adds the layer of caching. > > Also, I would expect the caching to be a generic mechanism that can be > used for all kcore reading, not just the printk ringbuffer. > > (I do not have any authoritative role for the kexec-tools. Just sharing > my thoughts on this patch.)
Thanks for looking at the patch and I appreciate the feedback! Your suggestion makes sense. Let me draft a v2 patch without any caching since I mostly care about bounding the memory usage here.
