Messages in this thread | | | Date | Sun, 7 Oct 2007 08:07:07 +0200 | From | Ingo Molnar <> | Subject | Re: [PATCH 0/2] Colored kernel output (run2) |
| |
* Oleg Verych <olecom@flower.upol.cz> wrote:
> > > * completely useless, if properly implemented in userspace (with > > > much reacher functionality). > > > > that's hogwash. No user-space runs during early bootup. (and yes i > > want a color code at glance if something hangs in early bootup) > > Nothing will color-code crashes, etc., etc. Control of the _kernel_ > > console by user-space is complete nonsense. > > If it is so important for major kernel developer like you, Ingo, then > why there's no scrollback at first place? Why nothing like that was > not implemented up until now?
even if it were true (which it isnt), that is not an argument against including a useful change that exists now and that people are interested in. (and yes, i have implemented kernel console improvements in the past and vga scrollback support was in fact amongst one of my first ever Linux kernel hacks so your comment is doubly wrong.)
> My first ever Linux hack was changing default console output color. I > think it was seven years ago. I though, it was not serious, if nobody > did that already (in the 2.2.14). > > Please, don't mix important stuff here. I know, what kernel console > is.
your arguments are not an answer to my technical points, which i'll repeat here:
| | [...] No user-space runs during early bootup. (and yes i want a | | color code at glance if something hangs in early bootup) Nothing | | will color-code crashes, etc., etc. Control of the _kernel_ console | | by user-space is complete nonsense.
today's console code development goes in exactly the opposite direction: we are including (formerly-) user-space console functionality in the kernel so that we can for example print oopses even if we are in X mode.
> > this is nice and robust functionality that i personally welcome. The > > default is not changed in any way. > > > > (btw., i corrected the subject line to remove the 'NAK'. Why do you > > think you can 'NAK' a patch in this field?) > > I added comment (like this), so anyone can skip reading body, if > headers are "Oleg Verych && NAK". In case if `NAK' have a magic > meaning in the LKML, like control characters in the tty, i'm sorry.
yes, a 'NAK' has a particular meaning on lkml.
> But how to express opinion quickly and easily?
by writing a quick email expressing your opinion and waiting to see the discussion play out itself ...
but it is very rude to 'NAK' a patch and it should only be done carefully.
Ingo - 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/
| |