Kalle Valo <kvalo@xxxxxxxxxxxxxxxx> writes: >> Since this is just debugfs then I imagine you could have a userspace >> program that would create the single blob/crash report from things it >> thinks is important, e.g.. `uname -a`, debugfs entries (fw stack >> traces, dbglog, etc), recent kernel log buffer, etc. It could even all >> be stored in plaintext (with binary data encoded as a hexdump). But >> that, I guess, could be cumbersome, at least initially, until all >> major distros adapt. > > Sure, we can push lots of this to user space. But what's the point? > > With the current approach we get a self-contained crash dump which the > user (be it a real person or automated) can store with a simple file > copy operatation and can be easily post-processed afterwards. What you > propose is a lot of work for everyone, most likely even more bugs and > without any clear benefits. At least the memory consumption should be > the same (if not even increase due to increased complexity). I forgot to mention that also I would not want to rely on debugfs except at the moment to deliver the dump to user space. I'm hoping that we would get a generic firmware crash dump support to cfg80211 (hopefully we can talk about that in Dusseldorf) and we might switch to ethtool or some another user space interface. Then it might be possible to enable this even without debugfs, if we are happy to take the hit on memory use. -- Kalle Valo -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
