Rahul Lakkireddy <rahul.lakkireddy@xxxxxxxxxxx> writes: > On Friday, March 03/30/18, 2018 at 16:09:07 +0530, Jiri Pirko wrote: >> Sat, Mar 24, 2018 at 11:56:33AM CET, rahul.lakkireddy@xxxxxxxxxxx wrote: >> >Add a new module crashdd that exports the /sys/kernel/crashdd/ >> >directory in second kernel, containing collected hardware/firmware >> >dumps. >> > >> >The sequence of actions done by device drivers to append their device >> >specific hardware/firmware logs to /sys/kernel/crashdd/ directory are >> >as follows: >> > >> >1. During probe (before hardware is initialized), device drivers >> >register to the crashdd module (via crashdd_add_dump()), with >> >callback function, along with buffer size and log name needed for >> >firmware/hardware log collection. >> > >> >2. Crashdd creates a driver's directory under >> >/sys/kernel/crashdd/<driver>. Then, it allocates the buffer with >> >> This smells. I need to identify the exact ASIC instance that produced >> the dump. To identify by driver name does not help me if I have multiple >> instances of the same driver. This looks wrong to me. This looks like >> a job for devlink where you have 1 devlink instance per 1 ASIC instance. >> >> Please see: >> http://patchwork.ozlabs.org/project/netdev/list/?series=36524 >> >> I bevieve that the solution in the patchset could be used for >> your usecase too. >> >> > > The sysfs approach proposed here had been dropped in favour exporting > the dumps as ELF notes in /proc/vmcore. > > Will be posting the new patches soon. The concern was actually how you identify which device that came from. Where you read the identifier changes but sysfs or /proc/vmcore the change remains valid. Eric _______________________________________________ kexec mailing list kexec@xxxxxxxxxxxxxxxxxxx http://lists.infradead.org/mailman/listinfo/kexec
