Peter Xu <pet...@redhat.com> writes: > On Thu, Aug 01, 2024 at 09:35:16AM -0300, Fabiano Rosas wrote: >> In preparation for adding new payload types to multifd, move most of >> the ram-related code into multifd-ram.c. Let's try to keep a semblance >> of layering by not mixing general multifd control flow with the >> details of transmitting pages of ram. >> >> There are still some pieces leftover, namely the p->normal, p->zero, >> etc variables that we use for zero page tracking and the packet >> allocation which is heavily dependent on the ram code. >> >> Signed-off-by: Fabiano Rosas <faro...@suse.de> > > The movement makes sense to me in general, but let's discuss whether nocomp > may need a better name. It could mean that we may want two new files: > multifd-ram.c to keep generic RAM stuff (which apply to nocomp/zlib/...) > then multifd-plain.c which contains no-comp case, perhaps.
I think 2 files would be too much. We'd just be jumping from one to another while reading code. The nocomp code is intimately related to the multifd-ram code. Should we just put it in a multifd-nocomp.c and that's it?
