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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
