[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20070702231837.GB9071@elf.ucw.cz>
Date: Tue, 3 Jul 2007 01:18:37 +0200
From: Pavel Machek <pavel@....cz>
To: Andi Kleen <ak@...e.de>
Cc: Stephen Hemminger <shemminger@...ux-foundation.org>,
Linus Torvalds <torvalds@...ux-foundation.org>,
Andrew Morton <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org
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@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists