Re: [PATCH 0/2] Colored kernel output (run2)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



* Oleg Verych <[email protected]> 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 [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]
  Powered by Linux