On Mon, Oct 27, 2008 at 10:32:43AM -0700, Eric W. Biederman wrote: > Avi Kivity <avi at redhat.com> writes: <snip> > > > > I wouldn't mind notifiers (with a nice comment explaining that you must know > > what you're doing, though that's the case with most kernel APIs). I'm fine with > > either approach. > > This is the 3rd request I have seen for a notifier. This is the first > request I have seen for code that must be executed in the kexec on > panic path. So history suggest to me that notifiers make it > unreasonably easy to get code onto the kexec on panic code path. > > Occasionally the kexec on panic code path is tested to see how > well it works in strange situations like being called from > a stack overflow etc. > > The rest of the history is that previous attempts like lkcd > had very programmer friendly interfaces, that worked fine > in test environments giving beautiful core dumps, but when things > broke in the field they were essentially useless. The kdump > approach is still not completely reliable but it does work > well enough that people get useful crash dumps sometimes. > > I feel anything that makes the kexec on panic code path harder > to verify it will work when things are crazy broken, like > a notifier is something we should avoid. I am still wondering if a simple function pointer (instead of a full notifier interface) would be good enough. It looks like a reasonable tradeoff. I think I will get flamed if I try to pull to the core a bunch of code that always lived in the KVM module. 8) And even if we pull those functions to the core, we will still have a function pointer on the new code anyway, because we would need to support vmx and svm. -- Eduardo
