On 7/29/26 10:53, Breno Leitao wrote: > On Wed, Jul 29, 2026 at 09:25:16AM +0200, David Hildenbrand (Arm) wrote: >> On 7/29/26 00:07, Breno Leitao wrote: >>> I have a draft of the selftest in C already and I will give it more bake >>> time, and I will submit it until EOW. >> >> IMHO there is no need to rush this test here, we could merge it after the >> main work. >> >> We neglected our selftests quite a bit in the past, and that is biting us >> now. >> >> That's why I push back hard now (sorry) against stuff that is different than >> the >> rest and not easy to maintain. >> >> I know, hwpoison-panic is a destructive test, but I really don't think we >> should >> just merge mostly unreviewed bash tests that will just bitrot. >> >> Which makes me wonder now: should this actually be a selftest? It's nothing >> one >> would just want to run in a CI. It will crash your machine. >> >> Maybe this should just be a tool in tools/mm? I really think so. So having a >> nice C-level hwpoison-panic.c in tools/mm might be the way to go. > > Agreed. In v6 [0] I actually removed the selftest entirely, since the value > wasn't clear and it seemed like an ugly duckling. > > It seems tools/mm would be a good fit, and make a better home for this > type of "test". > > Given more changes coming in memory failure (at least from my side > [1][2]), I think it would be a good idea to create a subdirectory > (tools/mm/memory-failure) and keep these semi-destructive tools in there. Is > this the right direction?
Makes sense to me. > >> So let's rather make this test well maintainable and have it properly >> reviewed >> than rushing something suboptimal. > > Sounds good. I'll move this to tools/mm and resubmit. Given Andrew has > removed the selftest from mm-unstable while keeping the rest of the > series (which is fully reviewed and frictionless), so I'll focus on the > test tool now and send it separately. Avoid bash scripts, please :) -- Cheers, David
