On Tue, 8 Dec 2020 15:26:10 +0100 Andrew Jones <drjones@xxxxxxxxxx> wrote: [...] > > > are not apparent when the memory is zeroed. I do not think anyone > > > wants to waste time on resolving these bugs. > > > > I disagree. if a unit test has a bug, it should be fixed. > > > > some tests apparently need the allocator to clear the memory, while > > other tests depend on the memory being untouched. this is clearly > > impossible to solve without some kind of switch > > > > > > I would like to know what the others think about this issue too > > > > If the allocator supports memory being returned and then reallocated, > then the generic allocation API cannot guarantee that the memory is > untouched anyway. So, if a test requires untouched memory, it should > use a specific API. I think setup() should probably just set some > physical memory regions aside for that purpose, exposing them somehow > to unit tests. The unit tests can then do anything they want with > them. The generic API might as well continue zeroing memory by > default. I think I have an idea for a solution that will allow for untouched pages and zeroed pages, on request, without any additional changes. Give me a few days ;) > I never got around to finishing my review of the memory areas. Maybe > that can be modified to support this "untouched" area simply by > labeling an area as such and by not accepting returned pages to that > area. > > Thanks, > drew >
