Messages in this thread | | | Date | Tue, 3 Jul 2007 01:18:37 +0200 | From | Pavel Machek <> | Subject | Re: blink driver power saving |
| |
Hi!
> > The patch makes sense. You don't need to poll every jiffie to find > > out if system has panic. > > The blink driver doesn't run on panic (or at least not on panic on > the same kernel). It runs always. It was designed to do the blinking > while the kdump kernel runs and writes the dump. > > > But I agree with Linus, it is the kind > > of patch that doesn't belong in the mainline kernel. Every developer > > seems to have built up a set of crappy/fragile debug tools, but these > > don't belong in the wild. > > Would you argue then that kdump also doesn't belong into the kernel? > The patch was designed to plug a hole in kdump (no visual feedback)
kexec -p <dump-capture-kernel-vmlinux-image> \ --initrd=<initrd-for-dump-capture-kernel> --args-linux \ --append="root=<root-dev> <arch-specific-options>"
....so we are already using initrd for dumping...? I'd say providing visual feedback is surely an userspace task.
Heck, with the keyboard leds you could probably blink them in a way telling user how much dump was done. Blink once then pause - 10%, blink twice then pause - 20%, ...
And yes, we already have LED subsystem capable of doing all this. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |