Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
Hi, Bill. Fri, Oct 12, 2007 at 09:16:01AM -0400: [] > >Coloring isn't useful. If it was, it would be implemented ~16 years ago. > > So anything that wasn't implemented a decade ago is not useful? Virtual > machines, software raid, fair scheduling, jumbo packets, SMT/SMP/NUMA > support, support for >4GB physical memory on x86, all fluff? Are we talking about VGA text mode or VT100 terminals? On what arch Linux was written to run shell and to build itself? IBM PC, if you don't know. Thus, your comment isn't funny or serious, sorry. I also distinguish important, needed, useful, preferable. > >>(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.) > > > >This `scrollback' is usual late boot / console one. If fact useful, > >until first tty switch or if `screen` cannot be used. But for some > >reason if scrolling region (DECSTBM) is less than whole screen, nothing > >works. And if width set to odd number of columns > > > >`stty columns $((80-1))` > > > >whole output becomes somewhat funny. > > I think by the time you get up enough to be running ill-advised commands > from shell, you are past "early boot." As i did dumb userspace coloring of kernel messages after this post, where text from bootloader, critical stuff are visible -- i.e. no truncated scrollback is needed, i can say, that this comment is bogus. I don't know what `ill-advised' commands are, but knowing how pipefs wasn't up early in <2.6.2X, i can say: *IT IS EARLY*. By me anything, that have /dev/console as controlling tty is early. > Your comments about scrollback not working right if you break it are > hopefully an attempt at humor. Cannot comment, because i don't understand this. I want scrollback in a defined scrolling region; i what line scrolling not be cursed, if columns number is odd. Now i have all this in userspace *early*, so i don't care about what ever implementors of that stuff in kernel thought. Bye. -- -o--=O`C #oo'L O <___=E M - 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/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
Alan Cox wrote: Jan's code is here today and it works fine for me. How can you coherently argue against the plain fact that his feature solves my usecases perfectly fine, So add a notifier for console printk output. Then you can keep whatever out of kernel patches you like for printk output in chinese, colour, swedish chef ... And of those the chinese is probably a good deal more relevant than the colour. If kernel printing were going to be done over, I would suggest that instead of the current fixed format strings, the format argument would be an index, an ordinal into an array of *char pointers, and the string so described would be used as the format. These strings and pointers could be put in two modules, one part of init to be released after boot like other init code, one resident. And by loading different modules the error messages could be as short, long, or colorful as desired, and in any language and/or character set available via escape sequence. Of course people would say it's larger than what we have, harder to use, would take a huge effort to convert existing messages... and that's all true. But as you said, the Chinese is probably more germane than colors. Think about it, kernel messages in Gaelic or even rap lyrics "Hate to tell you, it must be said, I can't boot your disk be dead." Or Latin, CRDOS had some comments in Latin and one PhD who thought his code was best described in BNF. To be serious, a notifier to a user program, *after boot*, would allow all this flexibility, although I still think it's too late to change. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
Oleg Verych wrote: Hallo, Ingo. On Sun, Oct 07, 2007 at 08:07:07AM +0200, Ingo Molnar wrote: To clarify. `Scrollback' here is *useful* scrollback during early boot and OOPs (which is absent, AFAIK), "nothing like that" is coloring of the messages by loglevel. 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. Coloring isn't useful. If it was, it would be implemented ~16 years ago. So anything that wasn't implemented a decade ago is not useful? Virtual machines, software raid, fair scheduling, jumbo packets, SMT/SMP/NUMA support, support for >4GB physical memory on x86, all fluff? (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.) This `scrollback' is usual late boot / console one. If fact useful, until first tty switch or if `screen` cannot be used. But for some reason if scrolling region (DECSTBM) is less than whole screen, nothing works. And if width set to odd number of columns `stty columns $((80-1))` whole output becomes somewhat funny. I think by the time you get up enough to be running ill-advised commands from shell, you are past "early boot." Your comments about scrollback not working right if you break it are hopefully an attempt at humor. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - 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/
Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage
Oleg Verych wrote: Hallo, Ingo. On Sun, Oct 07, 2007 at 08:07:07AM +0200, Ingo Molnar wrote: To clarify. `Scrollback' here is *useful* scrollback during early boot and OOPs (which is absent, AFAIK), nothing like that is coloring of the messages by loglevel. 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. Coloring isn't useful. If it was, it would be implemented ~16 years ago. So anything that wasn't implemented a decade ago is not useful? Virtual machines, software raid, fair scheduling, jumbo packets, SMT/SMP/NUMA support, support for 4GB physical memory on x86, all fluff? (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.) This `scrollback' is usual late boot / console one. If fact useful, until first tty switch or if `screen` cannot be used. But for some reason if scrolling region (DECSTBM) is less than whole screen, nothing works. And if width set to odd number of columns `stty columns $((80-1))` whole output becomes somewhat funny. I think by the time you get up enough to be running ill-advised commands from shell, you are past early boot. Your comments about scrollback not working right if you break it are hopefully an attempt at humor. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - 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/
Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage
Alan Cox wrote: Jan's code is here today and it works fine for me. How can you coherently argue against the plain fact that his feature solves my usecases perfectly fine, So add a notifier for console printk output. Then you can keep whatever out of kernel patches you like for printk output in chinese, colour, swedish chef ... And of those the chinese is probably a good deal more relevant than the colour. If kernel printing were going to be done over, I would suggest that instead of the current fixed format strings, the format argument would be an index, an ordinal into an array of *char pointers, and the string so described would be used as the format. These strings and pointers could be put in two modules, one part of init to be released after boot like other init code, one resident. And by loading different modules the error messages could be as short, long, or colorful as desired, and in any language and/or character set available via escape sequence. Of course people would say it's larger than what we have, harder to use, would take a huge effort to convert existing messages... and that's all true. But as you said, the Chinese is probably more germane than colors. Think about it, kernel messages in Gaelic or even rap lyrics Hate to tell you, it must be said, I can't boot your disk be dead. Or Latin, CRDOS had some comments in Latin and one PhD who thought his code was best described in BNF. To be serious, a notifier to a user program, *after boot*, would allow all this flexibility, although I still think it's too late to change. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - 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/
Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage
Hi, Bill. Fri, Oct 12, 2007 at 09:16:01AM -0400: [] Coloring isn't useful. If it was, it would be implemented ~16 years ago. So anything that wasn't implemented a decade ago is not useful? Virtual machines, software raid, fair scheduling, jumbo packets, SMT/SMP/NUMA support, support for 4GB physical memory on x86, all fluff? Are we talking about VGA text mode or VT100 terminals? On what arch Linux was written to run shell and to build itself? IBM PC, if you don't know. Thus, your comment isn't funny or serious, sorry. I also distinguish important, needed, useful, preferable. (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.) This `scrollback' is usual late boot / console one. If fact useful, until first tty switch or if `screen` cannot be used. But for some reason if scrolling region (DECSTBM) is less than whole screen, nothing works. And if width set to odd number of columns `stty columns $((80-1))` whole output becomes somewhat funny. I think by the time you get up enough to be running ill-advised commands from shell, you are past early boot. As i did dumb userspace coloring of kernel messages after this post, where text from bootloader, critical stuff are visible -- i.e. no truncated scrollback is needed, i can say, that this comment is bogus. I don't know what `ill-advised' commands are, but knowing how pipefs wasn't up early in 2.6.2X, i can say: *IT IS EARLY*. By me anything, that have /dev/console as controlling tty is early. Your comments about scrollback not working right if you break it are hopefully an attempt at humor. Cannot comment, because i don't understand this. I want scrollback in a defined scrolling region; i what line scrolling not be cursed, if columns number is odd. Now i have all this in userspace *early*, so i don't care about what ever implementors of that stuff in kernel thought. Bye. -- -o--=O`C #oo'L O ___=E M - 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/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On Sun, Oct 07, 2007 at 09:56:09PM +0200, Jan Engelhardt wrote: > > On Oct 7 2007 21:13, Willy Tarreau wrote: > >There are two distinct populations : > > - those [...] > >who would never have imagined that pressing Escape > >during the boot of windows 3.1/95 provided them with the full text > >messages. > > This is news to me. DOS always showed messages, and under Win95, > it was either F8 or removing logo.sys. I did troubleshoot it ;-) You remember that you could start them both from DOS by typing "win" ? If you hit ESC during the first seconds when the logo showed, you could get back to text mode to see the messages. > > - those who are troubleshooting their system [...] > > > >I personally fit in the second category. > > > >I would say that while I'm not particularly fond of flashy colors > >everywhere > > I have to agree so really. Just because there's a color option for > everything does not mean one should use it. > > In fact, I moved away[2] from the default Midnight Commander styling > because it's just - as Dave calls it - salad colors[1]. I found them "fun", it reminded me of the DOS-version of borland C, 15 years ago :-) > Some is good, as long as it is not excessive. While I could imagine that > Knoppix will abuse the feature and use vt.printk_color=9,9,9,9,11,10,12, > this is not what serious people would do. One solution against this and which may satisfy people who are against this idea, would be to just manipulate the bold and reverse attributes for errors. On VGA consoles, this would translate into printing in white instead of grey, and it could also work on ANSI/vt100 terminals. After all, if the initial intention was to report errors in a more noticeable way, let's not let the user choose the colors and have them defined the hard way. It will prevent the salad colors from appearing. Willy - 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/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On Sun, Oct 07, 2007 at 09:47:25PM +0200, Oleg Verych wrote: > On Sun, Oct 07, 2007 at 09:13:09PM +0200, Willy Tarreau wrote: > > On Sun, Oct 07, 2007 at 08:47:52PM +0200, Rene Herman wrote: > > > On 10/07/2007 06:12 PM, Ingo Molnar wrote: > > > > > > >* Oleg Verych <[EMAIL PROTECTED]> wrote: > > > > > > >>Coloring isn't useful. If it was, it would be implemented ~16 years > > > >>ago. > > > > > > > >Congratulations, this is the most stupid argument i've ever read on > > > >lkml. > [] > > I would say that while I'm not particularly fond of flashy colors > > everywhere, I think that being able to use colors to indicate particular > > actions in progress or conditions can be a good thing. RAID errors, > > devices disabled due to command-line parameters, and general anomalies > > which can cause a hang or panic a few line laters are worth coloring. > > That *is* the coloring, i'm talking about. > > > And I don't believe in userland's help here, because for that type of > > messages, the indication should be returned immediately. > > In the very buggy cases, i think, everything just hang. Otherwise > initramfs stuff can deal with it. > > > For instance, anyone who has experienced read errors on and IDE disk > > knows that it can literally take hours/days to boot, after displaying > > thousands of messages. Here, having the ability to see that no IRQ was > > assigned or something like this could help. > > As i'm pretty much in all that text(tty)-mode stuff anyway, maybe after > some time i will propose something klibc/tty based. Mainly a bit of user > interface: split scrolling regions for errors and notifications; flexible > color schemas (keyword highlighting); keyboard events. Of course it will > work in such IDE cases, only if driver is a module. But what I cannot understand is how you expect userspace to work while the lines are being displayed. If this is just to repaint the screen once everything is up, it is 100% useless. I'm interested in seeing errors _while_ they are happening. Basically, I need no color if the machine boots correctly. Willy - 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/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On Monday 08 October 2007 00:10:10 Rene Herman wrote: > I find Alan's suggestion to provide the functionality the same way you'd > provide for translated kernel messages (seeing as how there also are people > that want those) much more sensible. By the way, I agree that this is the best approach. Feasibly, it could be used by the same splash engines you mention to colour their console redirect, though most of the engines I've seen (e.g. SuSE/Ubuntu) don't let you switch messages on until after init (at which point kernel colours are probably irrelevant). -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - 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/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On Mon, Oct 08, 2007 at 01:01:33AM +0200, Jan Engelhardt wrote: > > On Oct 8 2007 01:02, Oleg Verych wrote: > > > >If you are not going to see OOPes of new kernels running old distros, ask > >any perl hacker (as they lovely mentioned in lkml) to hack for you > >something like: > > > >sed -u -e ' > >/^<1/s_^_'$COLOR1'_ > >/^<2/s_^_'$COLOR2'_ > >/^<3/s_^_'$COLOR3'_ > >/^<4/s_^_'$COLOR4'_ > >/^<5/s_^_'$COLOR5'_ > >/^<6/s_^_'$COLOR6'_ > >/^<7/s_^_'$COLOR7'_ > >' < /proc/kmsg >/dev/tty > > > >place whole that perl shit on initrams of your kernel, run it in > >background as early as possible with switched off default console output > >(i.e. quiet boot). > > > >OVER. > > Speaking of over, this does not fly at all. If you call panic(), > for whatever reason you want, then the printk() is the last thing > that happens after that, you can declare userspace dead. > On oopses, it depends on their severity. Eventually procfs goes > whoops and the kmsg transmission mechanism does not work, and oh, > userspace can't help it. I can rephrase/repeat: Here's discussion about general usage and feature set. The Development/debugging of the kernel, especially early boot or hard core OOPs isn't covered. If a kernel developer wants to have nice looking OOPes, i bet, this has nothing to do with general purpose printk() and loglevels and the kernel, that usually must boot once, until next security update. This is just another debugging tool, that could be written faster than any of the fancy rewrites of the kernel's core. Written many many years ago with much reacher coloring features. - 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/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On Monday 08 October 2007 00:10:10 Rene Herman wrote: > On 10/08/2007 12:40 AM, Alistair John Strachan wrote: > > Splash screens are clearly cosmetic, and it's kind of shameful (imo) that > > important messages explaining real problems are obscured from view by > > functionless splash screens. > > They're not functionless. You (and I) might not care for the function, but > their function is providing a "slick" bootup. That's why so many if not > basically all distributions of recent origin use them. Go ask Ubuntu for > example. > > > Personally, I think muddying the vga colour argument with splash screen > > stuff is bogus, they're very functionally separable ideas. A coloured > > oops seems to be a good way of telling novice users what information is > > relevant to their bug report. > > But when they're hidden by a splash screen, you don't see them any better > when they're red than when they're white. Splash screens were not mentioned > as any sort of alternative, their prevalence was mentioned as indication > that VGA console is only ever getting less important. Obviously true, but that's not a reason to bar enhancements to the VGA console. Right now, there's no sane way to have a splash screen in userspace handle an oops, so people looking to reproduce and detect the root of a problem will inevitably fall back to VGA (or vesa, presumably), where colour might be useful. I recall seeing a distro kernel oops early in boot, where the palette had been corrupted by the splash so the oops wasn't readable. That's bad, right? Don't get me wrong, I don't care for the feature much, I just don't think "splash screens are defacto" is a reason to shy away from a feature that could be useful for novices reporting kernel bugs. These people are probably inbetween those that must have a shiny splash and those that fix the kernel bugs. Of course, what Alan said elsewhere about breaking things that work is a good reason to not add the feature, or at least make it only happen on a real display. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - 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/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
> is bogus, they're very functionally separable ideas. A coloured oops seems to > be a good way of telling novice users what information is relevant to their > bug report. Unless they are colour blind or on a system like a PDA with a mono display 8) - 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/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On 10/08/2007 12:40 AM, Alistair John Strachan wrote: Splash screens are clearly cosmetic, and it's kind of shameful (imo) that important messages explaining real problems are obscured from view by functionless splash screens. They're not functionless. You (and I) might not care for the function, but their function is providing a "slick" bootup. That's why so many if not basically all distributions of recent origin use them. Go ask Ubuntu for example. Personally, I think muddying the vga colour argument with splash screen stuff is bogus, they're very functionally separable ideas. A coloured oops seems to be a good way of telling novice users what information is relevant to their bug report. But when they're hidden by a splash screen, you don't see them any better when they're red than when they're white. Splash screens were not mentioned as any sort of alternative, their prevalence was mentioned as indication that VGA console is only ever getting less important. I find Alan's suggestion to provide the functionality the same way you'd provide for translated kernel messages (seeing as how there also are people that want those) much more sensible. Rene. - 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/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On Sunday 07 October 2007 20:13:09 you wrote: > On Sun, Oct 07, 2007 at 08:47:52PM +0200, Rene Herman wrote: > > On 10/07/2007 06:12 PM, Ingo Molnar wrote: > > >* Oleg Verych <[EMAIL PROTECTED]> wrote: > > >>Coloring isn't useful. If it was, it would be implemented ~16 years > > >>ago. > > > > > >Congratulations, this is the most stupid argument i've ever read on > > >lkml. > > > > "Ay. World is finished. Everyone can go home and watch Friends reruns > > now." > > > > But well, there actually have been worse arguments given that VGA console > > is getting less and less important. I recently did a perusal of > > alternative distributions and didn't find a single one that didn't > > default to having a splash screen hide the kernel during boot (and if I'm > > not mistaken, only one of them provided me with the option during > > installation to not boot into X immediately afterwards). > > I don't recall having seen any splash screen on Slackware. And fortunately, > the mainstream distros still provide the option to boot in text mode. Debian defaultly doesn't use framebuffer or any kind of splash screen. Splash screens are clearly cosmetic, and it's kind of shameful (imo) that important messages explaining real problems are obscured from view by functionless splash screens. Personally, I think muddying the vga colour argument with splash screen stuff is bogus, they're very functionally separable ideas. A coloured oops seems to be a good way of telling novice users what information is relevant to their bug report. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - 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/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On Oct 8 2007 01:02, Oleg Verych wrote: > >If you are not going to see OOPes of new kernels running old distros, ask >any perl hacker (as they lovely mentioned in lkml) to hack for you >something like: > >sed -u -e ' >/^<1/s_^_'$COLOR1'_ >/^<2/s_^_'$COLOR2'_ >/^<3/s_^_'$COLOR3'_ >/^<4/s_^_'$COLOR4'_ >/^<5/s_^_'$COLOR5'_ >/^<6/s_^_'$COLOR6'_ >/^<7/s_^_'$COLOR7'_ >' < /proc/kmsg >/dev/tty > >place whole that perl shit on initrams of your kernel, run it in >background as early as possible with switched off default console output >(i.e. quiet boot). > >OVER. Speaking of over, this does not fly at all. If you call panic(), for whatever reason you want, then the printk() is the last thing that happens after that, you can declare userspace dead. On oopses, it depends on their severity. Eventually procfs goes whoops and the kmsg transmission mechanism does not work, and oh, userspace can't help it. - 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/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On Sun, Oct 07, 2007 at 11:11:54PM +0200, Ingo Molnar wrote: > > * Willy Tarreau <[EMAIL PROTECTED]> wrote: > > > I would say that while I'm not particularly fond of flashy colors > > everywhere, I think that being able to use colors to indicate > > particular actions in progress or conditions can be a good thing. RAID > > errors, devices disabled due to command-line parameters, and general > > anomalies which can cause a hang or panic a few line laters are worth > > coloring. And I don't believe in userland's help here, because for > > that type of messages, the indication should be returned immediately. > > For instance, anyone who has experienced read errors on and IDE disk > > knows that it can literally take hours/days to boot, after displaying > > thousands of messages. Here, having the ability to see that no IRQ was > > assigned or something like this could help. > > Exactly. I'm also testing older distros quite regularly with new kernels > and there's it's useful to have an impression of a kernel's output at a > glance. > Adding _any_ userspace change (even if i wanted to do it, which i dont) > is out of question. TERM=linux attribute escape codes did not change for a decade (or so). Making greping and coloring in userspace by means of klibc (+ GNU sed) and initramfs will solve this easily, provided there's useful kernel->console[userspace] interface. Ugly hacks, like those patches, aren't for my view of an useful feature. > So these are distinct, well-defined usecases that nobody has brought > any coherent argument against yet. VGA isnt going away anytime soon, > certainly not on my testboxes. If you are not going to see OOPes of new kernels running old distros, ask any perl hacker (as they lovely mentioned in lkml) to hack for you something like: sed -u -e ' /^<1/s_^_'$COLOR1'_ /^<2/s_^_'$COLOR2'_ /^<3/s_^_'$COLOR3'_ /^<4/s_^_'$COLOR4'_ /^<5/s_^_'$COLOR5'_ /^<6/s_^_'$COLOR6'_ /^<7/s_^_'$COLOR7'_ ' < /proc/kmsg >/dev/tty place whole that perl shit on initrams of your kernel, run it in background as early as possible with switched off default console output (i.e. quiet boot). OVER. For really good output it would be better to have escape code to serialize printing, thus no coloring brain damage will appear in concurrent writes on the tty (multiple areas, cursor movements). And this is only start of what can be done here. - 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/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
> Jan's code is here today and it works fine for me. How can you > coherently argue against the plain fact that his feature solves my > usecases perfectly fine, So add a notifier for console printk output. Then you can keep whatever out of kernel patches you like for printk output in chinese, colour, swedish chef ... And of those the chinese is probably a good deal more relevant than the colour. Alan - 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/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
* Oleg Verych <[EMAIL PROTECTED]> wrote: > > For instance, anyone who has experienced read errors on and IDE disk > > knows that it can literally take hours/days to boot, after > > displaying thousands of messages. Here, having the ability to see > > that no IRQ was assigned or something like this could help. > > As i'm pretty much in all that text(tty)-mode stuff anyway, maybe > after some time i will propose something klibc/tty based. Mainly a bit > of user interface: split scrolling regions for errors and > notifications; flexible color schemas (keyword highlighting); keyboard > events. Of course it will work in such IDE cases, only if driver is a > module. Jan's code is here today and it works fine for me. How can you coherently argue against the plain fact that his feature solves my usecases perfectly fine, while your hypothetical solution clearly does not solve them? (Although i'm not too hopeful you'll give me a straight answer to my straight question, given your track record on lkml. It is almost as if you were more interested in ranting and in controversy than in the progress of Linux.) 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/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
* Willy Tarreau <[EMAIL PROTECTED]> wrote: > I would say that while I'm not particularly fond of flashy colors > everywhere, I think that being able to use colors to indicate > particular actions in progress or conditions can be a good thing. RAID > errors, devices disabled due to command-line parameters, and general > anomalies which can cause a hang or panic a few line laters are worth > coloring. And I don't believe in userland's help here, because for > that type of messages, the indication should be returned immediately. > For instance, anyone who has experienced read errors on and IDE disk > knows that it can literally take hours/days to boot, after displaying > thousands of messages. Here, having the ability to see that no IRQ was > assigned or something like this could help. Exactly. I'm also testing older distros quite regularly with new kernels and there's it's useful to have an impression of a kernel's output at a glance. Adding _any_ userspace change (even if i wanted to do it, which i dont) is out of question. So these are distinct, well-defined usecases that nobody has brought any coherent argument against yet. VGA isnt going away anytime soon, certainly not on my testboxes. 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/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On 10/07/2007 10:04 PM, Jan Engelhardt wrote: On Oct 7 2007 22:00, Rene Herman wrote: On 10/07/2007 09:56 PM, Jan Engelhardt wrote: Some is good, as long as it is not excessive. While I could imagine that Knoppix will abuse the feature and use vt.printk_color=9,9,9,9,11,10,12, this is not what serious people would do. [1] http://tinyurl.com/yr9zgq [2] http://tinyurl.com/234ba3 Given this discussion, I find it really appropriate that you are posting _graphics_ of your text screens :-) I can give you a VCSA file (as produced by /dev/vcsa1) if you like, complete with VCSA reader. No, the PNGs will do thanks, it was obviuously a bit of a cheap shot. Still, it _is_ somewhat of a comment on what's expected these days. Rene - 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/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On 10/07/2007 09:56 PM, Jan Engelhardt wrote: Some is good, as long as it is not excessive. While I could imagine that Knoppix will abuse the feature and use vt.printk_color=9,9,9,9,11,10,12, this is not what serious people would do. [1] http://tinyurl.com/yr9zgq [2] http://tinyurl.com/234ba3 Given this discussion, I find it really appropriate that you are posting _graphics_ of your text screens :-) Rene. - 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/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On Oct 7 2007 21:27, Rene Herman wrote: > > I saw you remark on FB console in a reply to Alan just now and I > quite agree with you. The (current) FB console is slow and I'll add > "dumb" myself. When you have a 1280x1024 screen available, you get > to do cool things like put up nice little windows and exclamation > mark icons on errors, not just pretend you're really 132x50 (or > whatever). CVIDIX, while card-dependent I think, is much better at speed than FB while still providing 720x400 or even higher. - 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/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On Oct 7 2007 22:00, Rene Herman wrote: > On 10/07/2007 09:56 PM, Jan Engelhardt wrote: > >> Some is good, as long as it is not excessive. While I could imagine that >> Knoppix will abuse the feature and use vt.printk_color=9,9,9,9,11,10,12, this >> is not what serious people would do. >> >> [1] http://tinyurl.com/yr9zgq >> [2] http://tinyurl.com/234ba3 > > Given this discussion, I find it really appropriate that you are posting > _graphics_ of your text screens :-) I can give you a VCSA file (as produced by /dev/vcsa1) if you like, complete with VCSA reader. - 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/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On 10/07/2007 09:13 PM, Willy Tarreau wrote: On Sun, Oct 07, 2007 at 08:47:52PM +0200, Rene Herman wrote: But well, there actually have been worse arguments given that VGA console is getting less and less important. I recently did a perusal of alternative distributions and didn't find a single one that didn't default to having a splash screen hide the kernel during boot (and if I'm not mistaken, only one of them provided me with the option during installation to not boot into X immediately afterwards). I don't recall having seen any splash screen on Slackware. Indeed, but that's the distribution I use and considered switching away from. Just my luck eh? :-\ There are two distinct populations : - those who are afraid of boot messages and prefer "splash" screens. Those people are most common users, grown in non-IT environments. They are happy to see a big logo on their BIOS to hide important boot errors, and they are the ones who would never have imagined that pressing Escape during the boot of windows 3.1/95 provided them with the full text messages. Basically, they want to ensure they will never have to worry about things they don't understand. Nor want to understand, often. - those who are troubleshooting their system in the early stages (kernel, filesystems, network, services, ...). These ones *need* boot messages. And there, depending on the hardware, sometimes the FB is better because it shows larger lines, sometimes it's worse because the scrollback is limited by too low memory. I personally fit in the second category. And I'm sure most people on this list do. As do I ofcourse. An operating system kernel development list might provide for a fairly non-average balanced population of "am / am not interested in the inner workings of computers". Given that most everyone these days uses a computer, it's still a really small percentage though -- and as evidenced by the bootsplash thing, even of Linux users (and I've in fact heard real-life people say they disliked the noisy Linux bootup due to "all those errors"). I would be miserably sad if I couldn't get my boot messages anymore. It already irritates me a lot to loose the ones displayed before switching to frame-buffer when a hang happens just afterwards... Oh quite. I use VGA console myself. But not being able to get to the bootup messages anymore even for people who do care is not the issue. It's about finding it a bit hard to get excited about colourization when the "obvious" way forward is so much more graphically oriented. As also commented in another reply just now, ways forward also tend to have their problems but this kind of "innovation" takes me back to the time when our favorite bulletins board adopted ANSI colours. Today, that seems just a tad pathetic... Again, it might not hurt any either, but sheesh. Rene. - 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/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On Oct 7 2007 21:13, Willy Tarreau wrote: >There are two distinct populations : > - those [...] >who would never have imagined that pressing Escape >during the boot of windows 3.1/95 provided them with the full text >messages. This is news to me. DOS always showed messages, and under Win95, it was either F8 or removing logo.sys. I did troubleshoot it ;-) > - those who are troubleshooting their system [...] > >I personally fit in the second category. > >I would say that while I'm not particularly fond of flashy colors >everywhere I have to agree so really. Just because there's a color option for everything does not mean one should use it. In fact, I moved away[2] from the default Midnight Commander styling because it's just - as Dave calls it - salad colors[1]. Some is good, as long as it is not excessive. While I could imagine that Knoppix will abuse the feature and use vt.printk_color=9,9,9,9,11,10,12, this is not what serious people would do. [1] http://tinyurl.com/yr9zgq [2] http://tinyurl.com/234ba3 >, I think that being able to use colors to indicate particular >actions in progress or conditions can be a good thing. RAID errors, >devices disabled due to command-line parameters, - 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/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On Sun, Oct 07, 2007 at 09:13:09PM +0200, Willy Tarreau wrote: > On Sun, Oct 07, 2007 at 08:47:52PM +0200, Rene Herman wrote: > > On 10/07/2007 06:12 PM, Ingo Molnar wrote: > > > > >* Oleg Verych <[EMAIL PROTECTED]> wrote: > > > > >>Coloring isn't useful. If it was, it would be implemented ~16 years > > >>ago. > > > > > >Congratulations, this is the most stupid argument i've ever read on > > >lkml. [] > I would say that while I'm not particularly fond of flashy colors > everywhere, I think that being able to use colors to indicate particular > actions in progress or conditions can be a good thing. RAID errors, > devices disabled due to command-line parameters, and general anomalies > which can cause a hang or panic a few line laters are worth coloring. That *is* the coloring, i'm talking about. > And I don't believe in userland's help here, because for that type of > messages, the indication should be returned immediately. In the very buggy cases, i think, everything just hang. Otherwise initramfs stuff can deal with it. > For instance, anyone who has experienced read errors on and IDE disk > knows that it can literally take hours/days to boot, after displaying > thousands of messages. Here, having the ability to see that no IRQ was > assigned or something like this could help. As i'm pretty much in all that text(tty)-mode stuff anyway, maybe after some time i will propose something klibc/tty based. Mainly a bit of user interface: split scrolling regions for errors and notifications; flexible color schemas (keyword highlighting); keyboard events. Of course it will work in such IDE cases, only if driver is a module. - 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/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On 10/07/2007 08:58 PM, Jan Engelhardt wrote: On Oct 7 2007 20:47, Rene Herman wrote: Coloring isn't useful. If it was, it would be implemented ~16 years ago. Congratulations, this is the most stupid argument i've ever read on lkml. "Ay. World is finished. Everyone can go home and watch Friends reruns now." But well, there actually have been worse arguments given that VGA console is getting less and less important. [...] Sure, that in itself needn't necesarily be of concern to anyone who, err, is not concerned but any such colouring feature appearing when there's only a smathering of people left that still cares about the VGA console in the first place really isn't all _that_ far out as an argument... In case you have not noticed, the coloring also applies to FB. As far as I can oversee, it's only "missing" for serial and PROMs. Must say I did concentrate on VGA, but the [...] bit in the quote above was about how everything I encountered put up a bootsplash hiding _everything_ and about booting into X immediately, not about FB... I saw you remark on FB console in a reply to Alan just now and I quite agree with you. The (current) FB console is slow and I'll add "dumb" myself. When you have a 1280x1024 screen available, you get to do cool things like put up nice little windows and exclamation mark icons on errors, not just pretend you're really 132x50 (or whatever). Alan's sketched more generic markup/unification would be The Way Forward it seems. Given that TWF is mostly defined as "That Which Is Not" (and how it seems to have a tendency to defend that status vigorously) telling me/us to shelve that objection for 10 years might be okay -- but generally I'm having a fairly hard time getting excited about printk colourizing. Rene. - 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/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On Sun, Oct 07, 2007 at 08:47:52PM +0200, Rene Herman wrote: > On 10/07/2007 06:12 PM, Ingo Molnar wrote: > > >* Oleg Verych <[EMAIL PROTECTED]> wrote: > > >>Coloring isn't useful. If it was, it would be implemented ~16 years > >>ago. > > > >Congratulations, this is the most stupid argument i've ever read on > >lkml. > > "Ay. World is finished. Everyone can go home and watch Friends reruns now." > > But well, there actually have been worse arguments given that VGA console > is getting less and less important. I recently did a perusal of alternative > distributions and didn't find a single one that didn't default to having a > splash screen hide the kernel during boot (and if I'm not mistaken, only > one of them provided me with the option during installation to not boot > into X immediately afterwards). I don't recall having seen any splash screen on Slackware. And fortunately, the mainstream distros still provide the option to boot in text mode. > Sure, that in itself needn't necesarily be of concern to anyone who, err, > is not concerned but any such colouring feature appearing when there's only > a smathering of people left that still cares about the VGA console in the > first place really isn't all _that_ far out as an argument... There are two distinct populations : - those who are afraid of boot messages and prefer "splash" screens. Those people are most common users, grown in non-IT environments. They are happy to see a big logo on their BIOS to hide important boot errors, and they are the ones who would never have imagined that pressing Escape during the boot of windows 3.1/95 provided them with the full text messages. Basically, they want to ensure they will never have to worry about things they don't understand. - those who are troubleshooting their system in the early stages (kernel, filesystems, network, services, ...). These ones *need* boot messages. And there, depending on the hardware, sometimes the FB is better because it shows larger lines, sometimes it's worse because the scrollback is limited by too low memory. I personally fit in the second category. And I'm sure most people on this list do. I would be miserably sad if I couldn't get my boot messages anymore. It already irritates me a lot to loose the ones displayed before switching to frame-buffer when a hang happens just afterwards... I would say that while I'm not particularly fond of flashy colors everywhere, I think that being able to use colors to indicate particular actions in progress or conditions can be a good thing. RAID errors, devices disabled due to command-line parameters, and general anomalies which can cause a hang or panic a few line laters are worth coloring. And I don't believe in userland's help here, because for that type of messages, the indication should be returned immediately. For instance, anyone who has experienced read errors on and IDE disk knows that it can literally take hours/days to boot, after displaying thousands of messages. Here, having the ability to see that no IRQ was assigned or something like this could help. Regards, Willy - 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/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On Oct 7 2007 20:47, Rene Herman wrote: > >> > Coloring isn't useful. If it was, it would be implemented ~16 years >> > ago. >> >> Congratulations, this is the most stupid argument i've ever read on lkml. > > "Ay. World is finished. Everyone can go home and watch Friends reruns now." > > But well, there actually have been worse arguments given that VGA console is > getting less and less important. >[...] > Sure, that in itself needn't necesarily be of concern to anyone who, err, is > not concerned but any such colouring feature appearing when there's only a > smathering of people left that still cares about the VGA console in the first > place really isn't all _that_ far out as an argument... In case you have not noticed, the coloring also applies to FB. As far as I can oversee, it's only "missing" for serial and PROMs. - 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/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On 10/07/2007 06:12 PM, Ingo Molnar wrote: * Oleg Verych <[EMAIL PROTECTED]> wrote: Coloring isn't useful. If it was, it would be implemented ~16 years ago. Congratulations, this is the most stupid argument i've ever read on lkml. "Ay. World is finished. Everyone can go home and watch Friends reruns now." But well, there actually have been worse arguments given that VGA console is getting less and less important. I recently did a perusal of alternative distributions and didn't find a single one that didn't default to having a splash screen hide the kernel during boot (and if I'm not mistaken, only one of them provided me with the option during installation to not boot into X immediately afterwards). Sure, that in itself needn't necesarily be of concern to anyone who, err, is not concerned but any such colouring feature appearing when there's only a smathering of people left that still cares about the VGA console in the first place really isn't all _that_ far out as an argument... Rene. - 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/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
On Oct 7 2007 13:10, Oleg Verych wrote: >This `scrollback' is usual late boot / console one. If fact useful, >until first tty switch or if `screen` cannot be used. But for some >reason if scrolling region (DECSTBM) is less than whole screen, nothing >works. Actually, scrolling begins to work once userspace starts, and the scrollback buffer (given enough size) still contains the first screenful when Linux started, which may include the bootloader (if the loader did not zero the screen before handing control over). - 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/
Re: "Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
* Oleg Verych <[EMAIL PROTECTED]> wrote: > > 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. > > Coloring isn't useful. If it was, it would be implemented ~16 years > ago. Congratulations, this is the most stupid argument i've ever read on lkml. 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/
"Re: [PATCH 0/2] Colored kernel output (run2)" + "`Subject:' usage"
Hallo, Ingo. On Sun, Oct 07, 2007 at 08:07:07AM +0200, Ingo Molnar wrote: > > * 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? To clarify. `Scrollback' here is *useful* scrollback during early boot and OOPs (which is absent, AFAIK), "nothing like that" is coloring of the messages by loglevel. > 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. Coloring isn't useful. If it was, it would be implemented ~16 years ago. > (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.) This `scrollback' is usual late boot / console one. If fact useful, until first tty switch or if `screen` cannot be used. But for some reason if scrolling region (DECSTBM) is less than whole screen, nothing works. And if width set to odd number of columns `stty columns $((80-1))` whole output becomes somewhat funny. > > 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) The kernel developer talks about what is important to him. This is not technical point. > | | Nothing will color-code crashes, etc., etc. Because without userspace kernel panics. And if something is broken very early, then time to do kernel development better (not to break working early booting stuff for everybody), rather than to talk about importance of the color. I think, same applies to kernel debugger, that still is not in mainline (AFAIK). > | | Control of the _kernel_ console by user-space is complete nonsense. Not control, but flexible coloring (any kind of highlighting), selecting of useful information, i.e. making output more user friendly. This are things, which all *users* (not developers) expect in boot process of the one's _machine_, as opposed to debugging (early boot) kernel bugs. > 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. I'm not sure what kind of printing it is. I do not use X much, but when i did, i recall MCE messages in xterm, when over-clocked CPU was going crazy, though. > > > 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 what about (NAK && ! any_important_kernel_developer_name)? > > 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 ... Quick is not for me (i did accepted "config NO" size reduction review, btw), but for those, who reads LKML or looks on archive search results. I just am amazed how `Subject' is miss-used. I personally like to have most of the interesting information gathered from all that thousands of (not only LKML) messages. But a thread with all-like-one subjects, subjects that for some reason are taking place on the screen of MUAs (empty space if they are the same). Thus, short (easy to get right) summary in subject is more that welcome by me. > but it is very rude to 'NAK' a patch and it should only be done > carefully. That was a review of the implementation, an opinion on whole idea. Idea of yet another ugly kernel functionality, just because *BSD kernels have one. I like highlighting, i like to make it very flexible, nice and interesting[0]. This is possible only in the userspace, right after first process ran from initramfs.
Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage
Hallo, Ingo. On Sun, Oct 07, 2007 at 08:07:07AM +0200, Ingo Molnar wrote: * 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? To clarify. `Scrollback' here is *useful* scrollback during early boot and OOPs (which is absent, AFAIK), nothing like that is coloring of the messages by loglevel. 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. Coloring isn't useful. If it was, it would be implemented ~16 years ago. (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.) This `scrollback' is usual late boot / console one. If fact useful, until first tty switch or if `screen` cannot be used. But for some reason if scrolling region (DECSTBM) is less than whole screen, nothing works. And if width set to odd number of columns `stty columns $((80-1))` whole output becomes somewhat funny. 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) The kernel developer talks about what is important to him. This is not technical point. | | Nothing will color-code crashes, etc., etc. Because without userspace kernel panics. And if something is broken very early, then time to do kernel development better (not to break working early booting stuff for everybody), rather than to talk about importance of the color. I think, same applies to kernel debugger, that still is not in mainline (AFAIK). | | Control of the _kernel_ console by user-space is complete nonsense. Not control, but flexible coloring (any kind of highlighting), selecting of useful information, i.e. making output more user friendly. This are things, which all *users* (not developers) expect in boot process of the one's _machine_, as opposed to debugging (early boot) kernel bugs. 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. I'm not sure what kind of printing it is. I do not use X much, but when i did, i recall MCE messages in xterm, when over-clocked CPU was going crazy, though. 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 what about (NAK ! any_important_kernel_developer_name)? 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 ... Quick is not for me (i did accepted config NO size reduction review, btw), but for those, who reads LKML or looks on archive search results. I just am amazed how `Subject' is miss-used. I personally like to have most of the interesting information gathered from all that thousands of (not only LKML) messages. But a thread with all-like-one subjects, subjects that for some reason are taking place on the screen of MUAs (empty space if they are the same). Thus, short (easy to get right) summary in subject is more that welcome by me. but it is very rude to 'NAK' a patch and it should only be done carefully. That was a review of the implementation, an opinion on whole idea. Idea of yet another ugly kernel functionality, just because *BSD kernels have one. I like highlighting, i like to make it very flexible, nice and interesting[0]. This is possible only in the userspace, right after first process ran from initramfs. This happens very quickly usually. And yes, this is not acceptable/available for kernel
Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage
* Oleg Verych [EMAIL PROTECTED] wrote: 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. Coloring isn't useful. If it was, it would be implemented ~16 years ago. Congratulations, this is the most stupid argument i've ever read on lkml. 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/
Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage
On Oct 7 2007 13:10, Oleg Verych wrote: This `scrollback' is usual late boot / console one. If fact useful, until first tty switch or if `screen` cannot be used. But for some reason if scrolling region (DECSTBM) is less than whole screen, nothing works. Actually, scrolling begins to work once userspace starts, and the scrollback buffer (given enough size) still contains the first screenful when Linux started, which may include the bootloader (if the loader did not zero the screen before handing control over). - 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/
Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage
On 10/07/2007 06:12 PM, Ingo Molnar wrote: * Oleg Verych [EMAIL PROTECTED] wrote: Coloring isn't useful. If it was, it would be implemented ~16 years ago. Congratulations, this is the most stupid argument i've ever read on lkml. Ay. World is finished. Everyone can go home and watch Friends reruns now. But well, there actually have been worse arguments given that VGA console is getting less and less important. I recently did a perusal of alternative distributions and didn't find a single one that didn't default to having a splash screen hide the kernel during boot (and if I'm not mistaken, only one of them provided me with the option during installation to not boot into X immediately afterwards). Sure, that in itself needn't necesarily be of concern to anyone who, err, is not concerned but any such colouring feature appearing when there's only a smathering of people left that still cares about the VGA console in the first place really isn't all _that_ far out as an argument... Rene. - 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/
Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage
On Oct 7 2007 20:47, Rene Herman wrote: Coloring isn't useful. If it was, it would be implemented ~16 years ago. Congratulations, this is the most stupid argument i've ever read on lkml. Ay. World is finished. Everyone can go home and watch Friends reruns now. But well, there actually have been worse arguments given that VGA console is getting less and less important. [...] Sure, that in itself needn't necesarily be of concern to anyone who, err, is not concerned but any such colouring feature appearing when there's only a smathering of people left that still cares about the VGA console in the first place really isn't all _that_ far out as an argument... In case you have not noticed, the coloring also applies to FB. As far as I can oversee, it's only missing for serial and PROMs. - 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/
Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage
On Sun, Oct 07, 2007 at 08:47:52PM +0200, Rene Herman wrote: On 10/07/2007 06:12 PM, Ingo Molnar wrote: * Oleg Verych [EMAIL PROTECTED] wrote: Coloring isn't useful. If it was, it would be implemented ~16 years ago. Congratulations, this is the most stupid argument i've ever read on lkml. Ay. World is finished. Everyone can go home and watch Friends reruns now. But well, there actually have been worse arguments given that VGA console is getting less and less important. I recently did a perusal of alternative distributions and didn't find a single one that didn't default to having a splash screen hide the kernel during boot (and if I'm not mistaken, only one of them provided me with the option during installation to not boot into X immediately afterwards). I don't recall having seen any splash screen on Slackware. And fortunately, the mainstream distros still provide the option to boot in text mode. Sure, that in itself needn't necesarily be of concern to anyone who, err, is not concerned but any such colouring feature appearing when there's only a smathering of people left that still cares about the VGA console in the first place really isn't all _that_ far out as an argument... There are two distinct populations : - those who are afraid of boot messages and prefer splash screens. Those people are most common users, grown in non-IT environments. They are happy to see a big logo on their BIOS to hide important boot errors, and they are the ones who would never have imagined that pressing Escape during the boot of windows 3.1/95 provided them with the full text messages. Basically, they want to ensure they will never have to worry about things they don't understand. - those who are troubleshooting their system in the early stages (kernel, filesystems, network, services, ...). These ones *need* boot messages. And there, depending on the hardware, sometimes the FB is better because it shows larger lines, sometimes it's worse because the scrollback is limited by too low memory. I personally fit in the second category. And I'm sure most people on this list do. I would be miserably sad if I couldn't get my boot messages anymore. It already irritates me a lot to loose the ones displayed before switching to frame-buffer when a hang happens just afterwards... I would say that while I'm not particularly fond of flashy colors everywhere, I think that being able to use colors to indicate particular actions in progress or conditions can be a good thing. RAID errors, devices disabled due to command-line parameters, and general anomalies which can cause a hang or panic a few line laters are worth coloring. And I don't believe in userland's help here, because for that type of messages, the indication should be returned immediately. For instance, anyone who has experienced read errors on and IDE disk knows that it can literally take hours/days to boot, after displaying thousands of messages. Here, having the ability to see that no IRQ was assigned or something like this could help. Regards, Willy - 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/
Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage
On 10/07/2007 08:58 PM, Jan Engelhardt wrote: On Oct 7 2007 20:47, Rene Herman wrote: Coloring isn't useful. If it was, it would be implemented ~16 years ago. Congratulations, this is the most stupid argument i've ever read on lkml. Ay. World is finished. Everyone can go home and watch Friends reruns now. But well, there actually have been worse arguments given that VGA console is getting less and less important. [...] Sure, that in itself needn't necesarily be of concern to anyone who, err, is not concerned but any such colouring feature appearing when there's only a smathering of people left that still cares about the VGA console in the first place really isn't all _that_ far out as an argument... In case you have not noticed, the coloring also applies to FB. As far as I can oversee, it's only missing for serial and PROMs. Must say I did concentrate on VGA, but the [...] bit in the quote above was about how everything I encountered put up a bootsplash hiding _everything_ and about booting into X immediately, not about FB... I saw you remark on FB console in a reply to Alan just now and I quite agree with you. The (current) FB console is slow and I'll add dumb myself. When you have a 1280x1024 screen available, you get to do cool things like put up nice little windows and exclamation mark icons on errors, not just pretend you're really 132x50 (or whatever). Alan's sketched more generic markup/unification would be The Way Forward it seems. Given that TWF is mostly defined as That Which Is Not (and how it seems to have a tendency to defend that status vigorously) telling me/us to shelve that objection for 10 years might be okay -- but generally I'm having a fairly hard time getting excited about printk colourizing. Rene. - 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/
Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage
On Sun, Oct 07, 2007 at 09:13:09PM +0200, Willy Tarreau wrote: On Sun, Oct 07, 2007 at 08:47:52PM +0200, Rene Herman wrote: On 10/07/2007 06:12 PM, Ingo Molnar wrote: * Oleg Verych [EMAIL PROTECTED] wrote: Coloring isn't useful. If it was, it would be implemented ~16 years ago. Congratulations, this is the most stupid argument i've ever read on lkml. [] I would say that while I'm not particularly fond of flashy colors everywhere, I think that being able to use colors to indicate particular actions in progress or conditions can be a good thing. RAID errors, devices disabled due to command-line parameters, and general anomalies which can cause a hang or panic a few line laters are worth coloring. That *is* the coloring, i'm talking about. And I don't believe in userland's help here, because for that type of messages, the indication should be returned immediately. In the very buggy cases, i think, everything just hang. Otherwise initramfs stuff can deal with it. For instance, anyone who has experienced read errors on and IDE disk knows that it can literally take hours/days to boot, after displaying thousands of messages. Here, having the ability to see that no IRQ was assigned or something like this could help. As i'm pretty much in all that text(tty)-mode stuff anyway, maybe after some time i will propose something klibc/tty based. Mainly a bit of user interface: split scrolling regions for errors and notifications; flexible color schemas (keyword highlighting); keyboard events. Of course it will work in such IDE cases, only if driver is a module. - 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/
Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage
On 10/07/2007 09:13 PM, Willy Tarreau wrote: On Sun, Oct 07, 2007 at 08:47:52PM +0200, Rene Herman wrote: But well, there actually have been worse arguments given that VGA console is getting less and less important. I recently did a perusal of alternative distributions and didn't find a single one that didn't default to having a splash screen hide the kernel during boot (and if I'm not mistaken, only one of them provided me with the option during installation to not boot into X immediately afterwards). I don't recall having seen any splash screen on Slackware. Indeed, but that's the distribution I use and considered switching away from. Just my luck eh? :-\ There are two distinct populations : - those who are afraid of boot messages and prefer splash screens. Those people are most common users, grown in non-IT environments. They are happy to see a big logo on their BIOS to hide important boot errors, and they are the ones who would never have imagined that pressing Escape during the boot of windows 3.1/95 provided them with the full text messages. Basically, they want to ensure they will never have to worry about things they don't understand. Nor want to understand, often. - those who are troubleshooting their system in the early stages (kernel, filesystems, network, services, ...). These ones *need* boot messages. And there, depending on the hardware, sometimes the FB is better because it shows larger lines, sometimes it's worse because the scrollback is limited by too low memory. I personally fit in the second category. And I'm sure most people on this list do. As do I ofcourse. An operating system kernel development list might provide for a fairly non-average balanced population of am / am not interested in the inner workings of computers. Given that most everyone these days uses a computer, it's still a really small percentage though -- and as evidenced by the bootsplash thing, even of Linux users (and I've in fact heard real-life people say they disliked the noisy Linux bootup due to all those errors). I would be miserably sad if I couldn't get my boot messages anymore. It already irritates me a lot to loose the ones displayed before switching to frame-buffer when a hang happens just afterwards... Oh quite. I use VGA console myself. But not being able to get to the bootup messages anymore even for people who do care is not the issue. It's about finding it a bit hard to get excited about colourization when the obvious way forward is so much more graphically oriented. As also commented in another reply just now, ways forward also tend to have their problems but this kind of innovation takes me back to the time when our favorite bulletins board adopted ANSI colours. Today, that seems just a tad pathetic... Again, it might not hurt any either, but sheesh. Rene. - 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/
Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage
On Oct 7 2007 21:13, Willy Tarreau wrote: There are two distinct populations : - those [...] who would never have imagined that pressing Escape during the boot of windows 3.1/95 provided them with the full text messages. This is news to me. DOS always showed messages, and under Win95, it was either F8 or removing logo.sys. I did troubleshoot it ;-) - those who are troubleshooting their system [...] I personally fit in the second category. I would say that while I'm not particularly fond of flashy colors everywhere I have to agree so really. Just because there's a color option for everything does not mean one should use it. In fact, I moved away[2] from the default Midnight Commander styling because it's just - as Dave calls it - salad colors[1]. Some is good, as long as it is not excessive. While I could imagine that Knoppix will abuse the feature and use vt.printk_color=9,9,9,9,11,10,12, this is not what serious people would do. [1] http://tinyurl.com/yr9zgq [2] http://tinyurl.com/234ba3 , I think that being able to use colors to indicate particular actions in progress or conditions can be a good thing. RAID errors, devices disabled due to command-line parameters, - 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/
Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage
On 10/07/2007 09:56 PM, Jan Engelhardt wrote: Some is good, as long as it is not excessive. While I could imagine that Knoppix will abuse the feature and use vt.printk_color=9,9,9,9,11,10,12, this is not what serious people would do. [1] http://tinyurl.com/yr9zgq [2] http://tinyurl.com/234ba3 Given this discussion, I find it really appropriate that you are posting _graphics_ of your text screens :-) Rene. - 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/
Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage
On Oct 7 2007 21:27, Rene Herman wrote: I saw you remark on FB console in a reply to Alan just now and I quite agree with you. The (current) FB console is slow and I'll add dumb myself. When you have a 1280x1024 screen available, you get to do cool things like put up nice little windows and exclamation mark icons on errors, not just pretend you're really 132x50 (or whatever). CVIDIX, while card-dependent I think, is much better at speed than FB while still providing 720x400 or even higher. - 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/
Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage
On Oct 7 2007 22:00, Rene Herman wrote: On 10/07/2007 09:56 PM, Jan Engelhardt wrote: Some is good, as long as it is not excessive. While I could imagine that Knoppix will abuse the feature and use vt.printk_color=9,9,9,9,11,10,12, this is not what serious people would do. [1] http://tinyurl.com/yr9zgq [2] http://tinyurl.com/234ba3 Given this discussion, I find it really appropriate that you are posting _graphics_ of your text screens :-) I can give you a VCSA file (as produced by /dev/vcsa1) if you like, complete with VCSA reader. - 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/
Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage
On 10/07/2007 10:04 PM, Jan Engelhardt wrote: On Oct 7 2007 22:00, Rene Herman wrote: On 10/07/2007 09:56 PM, Jan Engelhardt wrote: Some is good, as long as it is not excessive. While I could imagine that Knoppix will abuse the feature and use vt.printk_color=9,9,9,9,11,10,12, this is not what serious people would do. [1] http://tinyurl.com/yr9zgq [2] http://tinyurl.com/234ba3 Given this discussion, I find it really appropriate that you are posting _graphics_ of your text screens :-) I can give you a VCSA file (as produced by /dev/vcsa1) if you like, complete with VCSA reader. No, the PNGs will do thanks, it was obviuously a bit of a cheap shot. Still, it _is_ somewhat of a comment on what's expected these days. Rene - 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/
Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage
* Willy Tarreau [EMAIL PROTECTED] wrote: I would say that while I'm not particularly fond of flashy colors everywhere, I think that being able to use colors to indicate particular actions in progress or conditions can be a good thing. RAID errors, devices disabled due to command-line parameters, and general anomalies which can cause a hang or panic a few line laters are worth coloring. And I don't believe in userland's help here, because for that type of messages, the indication should be returned immediately. For instance, anyone who has experienced read errors on and IDE disk knows that it can literally take hours/days to boot, after displaying thousands of messages. Here, having the ability to see that no IRQ was assigned or something like this could help. Exactly. I'm also testing older distros quite regularly with new kernels and there's it's useful to have an impression of a kernel's output at a glance. Adding _any_ userspace change (even if i wanted to do it, which i dont) is out of question. So these are distinct, well-defined usecases that nobody has brought any coherent argument against yet. VGA isnt going away anytime soon, certainly not on my testboxes. 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/
Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage
* Oleg Verych [EMAIL PROTECTED] wrote: For instance, anyone who has experienced read errors on and IDE disk knows that it can literally take hours/days to boot, after displaying thousands of messages. Here, having the ability to see that no IRQ was assigned or something like this could help. As i'm pretty much in all that text(tty)-mode stuff anyway, maybe after some time i will propose something klibc/tty based. Mainly a bit of user interface: split scrolling regions for errors and notifications; flexible color schemas (keyword highlighting); keyboard events. Of course it will work in such IDE cases, only if driver is a module. Jan's code is here today and it works fine for me. How can you coherently argue against the plain fact that his feature solves my usecases perfectly fine, while your hypothetical solution clearly does not solve them? (Although i'm not too hopeful you'll give me a straight answer to my straight question, given your track record on lkml. It is almost as if you were more interested in ranting and in controversy than in the progress of Linux.) 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/
Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage
Jan's code is here today and it works fine for me. How can you coherently argue against the plain fact that his feature solves my usecases perfectly fine, So add a notifier for console printk output. Then you can keep whatever out of kernel patches you like for printk output in chinese, colour, swedish chef ... And of those the chinese is probably a good deal more relevant than the colour. Alan - 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/
Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage
On Sun, Oct 07, 2007 at 11:11:54PM +0200, Ingo Molnar wrote: * Willy Tarreau [EMAIL PROTECTED] wrote: I would say that while I'm not particularly fond of flashy colors everywhere, I think that being able to use colors to indicate particular actions in progress or conditions can be a good thing. RAID errors, devices disabled due to command-line parameters, and general anomalies which can cause a hang or panic a few line laters are worth coloring. And I don't believe in userland's help here, because for that type of messages, the indication should be returned immediately. For instance, anyone who has experienced read errors on and IDE disk knows that it can literally take hours/days to boot, after displaying thousands of messages. Here, having the ability to see that no IRQ was assigned or something like this could help. Exactly. I'm also testing older distros quite regularly with new kernels and there's it's useful to have an impression of a kernel's output at a glance. Adding _any_ userspace change (even if i wanted to do it, which i dont) is out of question. TERM=linux attribute escape codes did not change for a decade (or so). Making greping and coloring in userspace by means of klibc (+ GNU sed) and initramfs will solve this easily, provided there's useful kernel-console[userspace] interface. Ugly hacks, like those patches, aren't for my view of an useful feature. So these are distinct, well-defined usecases that nobody has brought any coherent argument against yet. VGA isnt going away anytime soon, certainly not on my testboxes. If you are not going to see OOPes of new kernels running old distros, ask any perl hacker (as they lovely mentioned in lkml) to hack for you something like: sed -u -e ' /^1/s_^_'$COLOR1'_ /^2/s_^_'$COLOR2'_ /^3/s_^_'$COLOR3'_ /^4/s_^_'$COLOR4'_ /^5/s_^_'$COLOR5'_ /^6/s_^_'$COLOR6'_ /^7/s_^_'$COLOR7'_ ' /proc/kmsg /dev/tty place whole that perl shit on initrams of your kernel, run it in background as early as possible with switched off default console output (i.e. quiet boot). OVER. For really good output it would be better to have escape code to serialize printing, thus no coloring brain damage will appear in concurrent writes on the tty (multiple areas, cursor movements). And this is only start of what can be done here. - 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/
Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage
On Oct 8 2007 01:02, Oleg Verych wrote: If you are not going to see OOPes of new kernels running old distros, ask any perl hacker (as they lovely mentioned in lkml) to hack for you something like: sed -u -e ' /^1/s_^_'$COLOR1'_ /^2/s_^_'$COLOR2'_ /^3/s_^_'$COLOR3'_ /^4/s_^_'$COLOR4'_ /^5/s_^_'$COLOR5'_ /^6/s_^_'$COLOR6'_ /^7/s_^_'$COLOR7'_ ' /proc/kmsg /dev/tty place whole that perl shit on initrams of your kernel, run it in background as early as possible with switched off default console output (i.e. quiet boot). OVER. Speaking of over, this does not fly at all. If you call panic(), for whatever reason you want, then the printk() is the last thing that happens after that, you can declare userspace dead. On oopses, it depends on their severity. Eventually procfs goes whoops and the kmsg transmission mechanism does not work, and oh, userspace can't help it. - 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/
Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage
On Sunday 07 October 2007 20:13:09 you wrote: On Sun, Oct 07, 2007 at 08:47:52PM +0200, Rene Herman wrote: On 10/07/2007 06:12 PM, Ingo Molnar wrote: * Oleg Verych [EMAIL PROTECTED] wrote: Coloring isn't useful. If it was, it would be implemented ~16 years ago. Congratulations, this is the most stupid argument i've ever read on lkml. Ay. World is finished. Everyone can go home and watch Friends reruns now. But well, there actually have been worse arguments given that VGA console is getting less and less important. I recently did a perusal of alternative distributions and didn't find a single one that didn't default to having a splash screen hide the kernel during boot (and if I'm not mistaken, only one of them provided me with the option during installation to not boot into X immediately afterwards). I don't recall having seen any splash screen on Slackware. And fortunately, the mainstream distros still provide the option to boot in text mode. Debian defaultly doesn't use framebuffer or any kind of splash screen. Splash screens are clearly cosmetic, and it's kind of shameful (imo) that important messages explaining real problems are obscured from view by functionless splash screens. Personally, I think muddying the vga colour argument with splash screen stuff is bogus, they're very functionally separable ideas. A coloured oops seems to be a good way of telling novice users what information is relevant to their bug report. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - 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/
Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage
On 10/08/2007 12:40 AM, Alistair John Strachan wrote: Splash screens are clearly cosmetic, and it's kind of shameful (imo) that important messages explaining real problems are obscured from view by functionless splash screens. They're not functionless. You (and I) might not care for the function, but their function is providing a slick bootup. That's why so many if not basically all distributions of recent origin use them. Go ask Ubuntu for example. Personally, I think muddying the vga colour argument with splash screen stuff is bogus, they're very functionally separable ideas. A coloured oops seems to be a good way of telling novice users what information is relevant to their bug report. But when they're hidden by a splash screen, you don't see them any better when they're red than when they're white. Splash screens were not mentioned as any sort of alternative, their prevalence was mentioned as indication that VGA console is only ever getting less important. I find Alan's suggestion to provide the functionality the same way you'd provide for translated kernel messages (seeing as how there also are people that want those) much more sensible. Rene. - 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/
Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage
is bogus, they're very functionally separable ideas. A coloured oops seems to be a good way of telling novice users what information is relevant to their bug report. Unless they are colour blind or on a system like a PDA with a mono display 8) - 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/
Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage
On Mon, Oct 08, 2007 at 01:01:33AM +0200, Jan Engelhardt wrote: On Oct 8 2007 01:02, Oleg Verych wrote: If you are not going to see OOPes of new kernels running old distros, ask any perl hacker (as they lovely mentioned in lkml) to hack for you something like: sed -u -e ' /^1/s_^_'$COLOR1'_ /^2/s_^_'$COLOR2'_ /^3/s_^_'$COLOR3'_ /^4/s_^_'$COLOR4'_ /^5/s_^_'$COLOR5'_ /^6/s_^_'$COLOR6'_ /^7/s_^_'$COLOR7'_ ' /proc/kmsg /dev/tty place whole that perl shit on initrams of your kernel, run it in background as early as possible with switched off default console output (i.e. quiet boot). OVER. Speaking of over, this does not fly at all. If you call panic(), for whatever reason you want, then the printk() is the last thing that happens after that, you can declare userspace dead. On oopses, it depends on their severity. Eventually procfs goes whoops and the kmsg transmission mechanism does not work, and oh, userspace can't help it. I can rephrase/repeat: Here's discussion about general usage and feature set. The Development/debugging of the kernel, especially early boot or hard core OOPs isn't covered. If a kernel developer wants to have nice looking OOPes, i bet, this has nothing to do with general purpose printk() and loglevels and the kernel, that usually must boot once, until next security update. This is just another debugging tool, that could be written faster than any of the fancy rewrites of the kernel's core. Written many many years ago with much reacher coloring features. - 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/
Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage
On Monday 08 October 2007 00:10:10 Rene Herman wrote: On 10/08/2007 12:40 AM, Alistair John Strachan wrote: Splash screens are clearly cosmetic, and it's kind of shameful (imo) that important messages explaining real problems are obscured from view by functionless splash screens. They're not functionless. You (and I) might not care for the function, but their function is providing a slick bootup. That's why so many if not basically all distributions of recent origin use them. Go ask Ubuntu for example. Personally, I think muddying the vga colour argument with splash screen stuff is bogus, they're very functionally separable ideas. A coloured oops seems to be a good way of telling novice users what information is relevant to their bug report. But when they're hidden by a splash screen, you don't see them any better when they're red than when they're white. Splash screens were not mentioned as any sort of alternative, their prevalence was mentioned as indication that VGA console is only ever getting less important. Obviously true, but that's not a reason to bar enhancements to the VGA console. Right now, there's no sane way to have a splash screen in userspace handle an oops, so people looking to reproduce and detect the root of a problem will inevitably fall back to VGA (or vesa, presumably), where colour might be useful. I recall seeing a distro kernel oops early in boot, where the palette had been corrupted by the splash so the oops wasn't readable. That's bad, right? Don't get me wrong, I don't care for the feature much, I just don't think splash screens are defacto is a reason to shy away from a feature that could be useful for novices reporting kernel bugs. These people are probably inbetween those that must have a shiny splash and those that fix the kernel bugs. Of course, what Alan said elsewhere about breaking things that work is a good reason to not add the feature, or at least make it only happen on a real display. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - 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/
Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage
On Monday 08 October 2007 00:10:10 Rene Herman wrote: I find Alan's suggestion to provide the functionality the same way you'd provide for translated kernel messages (seeing as how there also are people that want those) much more sensible. By the way, I agree that this is the best approach. Feasibly, it could be used by the same splash engines you mention to colour their console redirect, though most of the engines I've seen (e.g. SuSE/Ubuntu) don't let you switch messages on until after init (at which point kernel colours are probably irrelevant). -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - 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/
Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage
On Sun, Oct 07, 2007 at 09:47:25PM +0200, Oleg Verych wrote: On Sun, Oct 07, 2007 at 09:13:09PM +0200, Willy Tarreau wrote: On Sun, Oct 07, 2007 at 08:47:52PM +0200, Rene Herman wrote: On 10/07/2007 06:12 PM, Ingo Molnar wrote: * Oleg Verych [EMAIL PROTECTED] wrote: Coloring isn't useful. If it was, it would be implemented ~16 years ago. Congratulations, this is the most stupid argument i've ever read on lkml. [] I would say that while I'm not particularly fond of flashy colors everywhere, I think that being able to use colors to indicate particular actions in progress or conditions can be a good thing. RAID errors, devices disabled due to command-line parameters, and general anomalies which can cause a hang or panic a few line laters are worth coloring. That *is* the coloring, i'm talking about. And I don't believe in userland's help here, because for that type of messages, the indication should be returned immediately. In the very buggy cases, i think, everything just hang. Otherwise initramfs stuff can deal with it. For instance, anyone who has experienced read errors on and IDE disk knows that it can literally take hours/days to boot, after displaying thousands of messages. Here, having the ability to see that no IRQ was assigned or something like this could help. As i'm pretty much in all that text(tty)-mode stuff anyway, maybe after some time i will propose something klibc/tty based. Mainly a bit of user interface: split scrolling regions for errors and notifications; flexible color schemas (keyword highlighting); keyboard events. Of course it will work in such IDE cases, only if driver is a module. But what I cannot understand is how you expect userspace to work while the lines are being displayed. If this is just to repaint the screen once everything is up, it is 100% useless. I'm interested in seeing errors _while_ they are happening. Basically, I need no color if the machine boots correctly. Willy - 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/
Re: Re: [PATCH 0/2] Colored kernel output (run2) + `Subject:' usage
On Sun, Oct 07, 2007 at 09:56:09PM +0200, Jan Engelhardt wrote: On Oct 7 2007 21:13, Willy Tarreau wrote: There are two distinct populations : - those [...] who would never have imagined that pressing Escape during the boot of windows 3.1/95 provided them with the full text messages. This is news to me. DOS always showed messages, and under Win95, it was either F8 or removing logo.sys. I did troubleshoot it ;-) You remember that you could start them both from DOS by typing win ? If you hit ESC during the first seconds when the logo showed, you could get back to text mode to see the messages. - those who are troubleshooting their system [...] I personally fit in the second category. I would say that while I'm not particularly fond of flashy colors everywhere I have to agree so really. Just because there's a color option for everything does not mean one should use it. In fact, I moved away[2] from the default Midnight Commander styling because it's just - as Dave calls it - salad colors[1]. I found them fun, it reminded me of the DOS-version of borland C, 15 years ago :-) Some is good, as long as it is not excessive. While I could imagine that Knoppix will abuse the feature and use vt.printk_color=9,9,9,9,11,10,12, this is not what serious people would do. One solution against this and which may satisfy people who are against this idea, would be to just manipulate the bold and reverse attributes for errors. On VGA consoles, this would translate into printing in white instead of grey, and it could also work on ANSI/vt100 terminals. After all, if the initial intention was to report errors in a more noticeable way, let's not let the user choose the colors and have them defined the hard way. It will prevent the salad colors from appearing. Willy - 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/
