On Thu, Aug 22, 2024 at 02:21:18PM -0300, Fabiano Rosas wrote: > 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?
Sure, as long as nocomp helpers have a proper prefix (like "plain") then it would be good. -- Peter Xu
