Hi! > > [..] combined > > with an automatic oops/panic/bug-report this would be _very_ useful I think. > > That would be nice addition IMHO. It'll be more complex since it'll > involve netconsole dumping and passing the klive session to the kernel > somehow (userland would be too unreliable to push the oops to the > server). The worst part is that oops dumping might expose random kernel > data (it could contain ssh keys as well), so I would either need to > purify the stack/code/register lines making the oops quite useless, or > not to show it at all (and only to show the count of the oopses > publically). A parameter could be used to tell the kernel if the whole > oops should be sent to the klive server or if only the notification an > oops should be sent (without sending the payload with potentially > sensitive data inside).
Well, you could remove everything that is not valid kernel text from backtrace. That should make ssh keys non-issue and still provide usefull information. Oh and you probably want to somehow identify modified kernels. Otherwise if I do some development on 2.3.4-foo5, you'll get many oopsen caused by my development code... it is getting complex. -- 64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
