On 2/17/25 13:19, Johannes Berg wrote: > 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? Yes, that's why it's marked as an RFC. > >> 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. Thank you for your feedback. > > johannes
