On Mon, 2025-02-17 at 12:44 +0200, Eugen Hristev wrote: > > At this moment going through devcoredump is not something that impacts > the idea of the implementation. Yeah. I don't think it _should_ go through it at all. > The whole reason of going through it (because things work without it as > well), is to see whether this has any kind of impact or not, and if > there is any kind of fit/reason of going through it. So it's just a trial balloon? > Devcoredump is involved because the whole core registration is similar > to a core area that devcoredump could use. Yeah but ... > For example, would it be interesting to have a handler going through all > devices, and have the dump areas already registered ? > Meaning, when there is a request to generate a core dump, one could > directly dump this area instead of calling back the driver, and provide > that to the userspace instead of the driver calling the dev_coredumpv by > its own. I'll be blunt ... so you _really_ haven't understood devcoredump then? It's really not doing this. It's not meant to do this... It's intended to dump data from inside the device when the device crashes. Please remove devcoredump involvement from this series. johannes
