Re: NAK nettiquete (was Re: "Re: [PATCH 0/2] Colored kernel output (run2)"
On Oct 7 2007 17:23, Alan Cox wrote: > >>>- If you want to do "pretty" boot up you do it in X or frame buffer >>>(which is going to get easier and easier with the X shift to kernel side >>>video support) >> >> fb is slow. Feels like a 9600bps serial line. > >So fix your fb. There is enough information to cover 2D scrolling for >most modern cards now. > >> Let everyone have his own fun. > >The point isn't to put everyones "fun" into the kernel, or by now it >would have become a steaming heap. We do have a steaming heap of obscure hardware drivers, actually. - 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: NAK nettiquete (was Re: "Re: [PATCH 0/2] Colored kernel output (run2)"
Em Sun, Oct 07, 2007 at 04:12:22PM +0100, Alan Cox escreveu: > > The few times I've tried to NAK something outright, I've always tried to > > attach > > plenty of technical explanation > > Fair comment to my "silly" response > > The problems I see are > > - We run on a lot more than VGA PC consoles > - We have serial consoles (which may or may not be VT132/ANSI compliant) > - The printk paths are run at IRQ time ASAP to get messages to console, > that could mean we split existing colour escape code processing and the > like. > - People redirect the console feed other places via ioctl. Some of them > parse "<%d>" as the start > > But most importantly: > > - If you want to do "pretty" boot up you do it in X or frame buffer > (which is going to get easier and easier with the X shift to kernel side > video support) > - If you want to do a coloured display after boot then this is a matter > for your logging tools > > As with translation the kernel is the wrong place to do this work. > > What I would much rather people thought about was > > - Marker modes for translation (so you know which bits of a message are > formatted up) > - More consistency on the use of "name: blah" to make it easier to parse > - Turning more messages from kernel logs to events when it makes sense > (eg "Disk Full", "Media Error", "CPU on fire") > > So if you want to do a pretty boot, then solve the big picture, the > framebuffer initrd graphical boot, the boot display, the combining of > artwork and messages in user space from initrd run code. > > 'leet kernel messages in flashing red are not really the problem that > needs solving to do this. Its kinda like we pronounce printk dead for first level error reporting. We are getting more and more closer to that with all the macros that do just that... I'm not following kernel development as I think I should be, but...: dev_printk dev_dbg dev_vdbg DCCP_WARN DCCP_CRIT DCCP_PR_DEBUG LIMIT_NETDEBUG With some more researching I'm sure I'd find more printk wrappers. But I guess this should make some sort of point: using these wrappers get us closer to what Alan wants: consistent printk messages. Such that the life of kcolorls like wrappers get to the point that the life of user level debugging loggers can jump and shout in happiness for providing even nifty popup messages on "modern desktops". As if the problem with modern desktops (or server consoles) was just that... gimme a way to configure wpa-psk on my brand new company notebook without having to resort to, ugh, command line assistance... Bluetooth without having to manually do "service bluetooth start"... - Arnaldo P.S.: I know that that is just in the making, dbus and a lot of other buzzwords that keep promising to solve these kinds of problems :-) - 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: NAK nettiquete (was Re: "Re: [PATCH 0/2] Colored kernel output (run2)"
> >- If you want to do "pretty" boot up you do it in X or frame buffer > >(which is going to get easier and easier with the X shift to kernel side > >video support) > > fb is slow. Feels like a 9600bps serial line. So fix your fb. There is enough information to cover 2D scrolling for most modern cards now. > Let everyone have his own fun. The point isn't to put everyones "fun" into the kernel, or by now it would have become a steaming heap. - 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: NAK nettiquete (was Re: "Re: [PATCH 0/2] Colored kernel output (run2)"
On Oct 7 2007 16:12, Alan Cox wrote: > >- We run on a lot more than VGA PC consoles >- We have serial consoles (which may or may not be VT132/ANSI compliant) Yes, and the serial driver does not usually pass on vc->vc_color to the real hardware. If it did, it would have to transform it back into an unportable ANSI code and send that. So we don't do that. >- The printk paths are run at IRQ time ASAP to get messages to console, >that could mean we split existing colour escape code processing and the >like. Oleg already persuaded me to add options to toally configure it out, so there is no impact for you. >- People redirect the console feed other places via ioctl. Some of them >parse "<%d>" as the start Interestingly enough, the part is not transferred over serial, but that seems another story. >- If you want to do "pretty" boot up you do it in X or frame buffer >(which is going to get easier and easier with the X shift to kernel side >video support) fb is slow. Feels like a 9600bps serial line. Let everyone have his own fun. - 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: NAK nettiquete (was Re: "Re: [PATCH 0/2] Colored kernel output (run2)"
> The few times I've tried to NAK something outright, I've always tried to > attach > plenty of technical explanation Fair comment to my "silly" response The problems I see are - We run on a lot more than VGA PC consoles - We have serial consoles (which may or may not be VT132/ANSI compliant) - The printk paths are run at IRQ time ASAP to get messages to console, that could mean we split existing colour escape code processing and the like. - People redirect the console feed other places via ioctl. Some of them parse "<%d>" as the start But most importantly: - If you want to do "pretty" boot up you do it in X or frame buffer (which is going to get easier and easier with the X shift to kernel side video support) - If you want to do a coloured display after boot then this is a matter for your logging tools As with translation the kernel is the wrong place to do this work. What I would much rather people thought about was - Marker modes for translation (so you know which bits of a message are formatted up) - More consistency on the use of "name: blah" to make it easier to parse - Turning more messages from kernel logs to events when it makes sense (eg "Disk Full", "Media Error", "CPU on fire") So if you want to do a pretty boot, then solve the big picture, the framebuffer initrd graphical boot, the boot display, the combining of artwork and messages in user space from initrd run code. 'leet kernel messages in flashing red are not really the problem that needs solving to do this. 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: NAK nettiquete (was Re: Re: [PATCH 0/2] Colored kernel output (run2)
The few times I've tried to NAK something outright, I've always tried to attach plenty of technical explanation Fair comment to my silly response The problems I see are - We run on a lot more than VGA PC consoles - We have serial consoles (which may or may not be VT132/ANSI compliant) - The printk paths are run at IRQ time ASAP to get messages to console, that could mean we split existing colour escape code processing and the like. - People redirect the console feed other places via ioctl. Some of them parse %d as the start But most importantly: - If you want to do pretty boot up you do it in X or frame buffer (which is going to get easier and easier with the X shift to kernel side video support) - If you want to do a coloured display after boot then this is a matter for your logging tools As with translation the kernel is the wrong place to do this work. What I would much rather people thought about was - Marker modes for translation (so you know which bits of a message are formatted up) - More consistency on the use of name: blah to make it easier to parse - Turning more messages from kernel logs to events when it makes sense (eg Disk Full, Media Error, CPU on fire) So if you want to do a pretty boot, then solve the big picture, the framebuffer initrd graphical boot, the boot display, the combining of artwork and messages in user space from initrd run code. 'leet kernel messages in flashing red are not really the problem that needs solving to do this. 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: NAK nettiquete (was Re: Re: [PATCH 0/2] Colored kernel output (run2)
On Oct 7 2007 16:12, Alan Cox wrote: - We run on a lot more than VGA PC consoles - We have serial consoles (which may or may not be VT132/ANSI compliant) Yes, and the serial driver does not usually pass on vc-vc_color to the real hardware. If it did, it would have to transform it back into an unportable ANSI code and send that. So we don't do that. - The printk paths are run at IRQ time ASAP to get messages to console, that could mean we split existing colour escape code processing and the like. Oleg already persuaded me to add options to toally configure it out, so there is no impact for you. - People redirect the console feed other places via ioctl. Some of them parse %d as the start Interestingly enough, the n part is not transferred over serial, but that seems another story. - If you want to do pretty boot up you do it in X or frame buffer (which is going to get easier and easier with the X shift to kernel side video support) fb is slow. Feels like a 9600bps serial line. Let everyone have his own fun. - 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: NAK nettiquete (was Re: Re: [PATCH 0/2] Colored kernel output (run2)
- If you want to do pretty boot up you do it in X or frame buffer (which is going to get easier and easier with the X shift to kernel side video support) fb is slow. Feels like a 9600bps serial line. So fix your fb. There is enough information to cover 2D scrolling for most modern cards now. Let everyone have his own fun. The point isn't to put everyones fun into the kernel, or by now it would have become a steaming heap. - 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: NAK nettiquete (was Re: Re: [PATCH 0/2] Colored kernel output (run2)
Em Sun, Oct 07, 2007 at 04:12:22PM +0100, Alan Cox escreveu: The few times I've tried to NAK something outright, I've always tried to attach plenty of technical explanation Fair comment to my silly response The problems I see are - We run on a lot more than VGA PC consoles - We have serial consoles (which may or may not be VT132/ANSI compliant) - The printk paths are run at IRQ time ASAP to get messages to console, that could mean we split existing colour escape code processing and the like. - People redirect the console feed other places via ioctl. Some of them parse %d as the start But most importantly: - If you want to do pretty boot up you do it in X or frame buffer (which is going to get easier and easier with the X shift to kernel side video support) - If you want to do a coloured display after boot then this is a matter for your logging tools As with translation the kernel is the wrong place to do this work. What I would much rather people thought about was - Marker modes for translation (so you know which bits of a message are formatted up) - More consistency on the use of name: blah to make it easier to parse - Turning more messages from kernel logs to events when it makes sense (eg Disk Full, Media Error, CPU on fire) So if you want to do a pretty boot, then solve the big picture, the framebuffer initrd graphical boot, the boot display, the combining of artwork and messages in user space from initrd run code. 'leet kernel messages in flashing red are not really the problem that needs solving to do this. Its kinda like we pronounce printk dead for first level error reporting. We are getting more and more closer to that with all the macros that do just that... I'm not following kernel development as I think I should be, but...: dev_printk dev_dbg dev_vdbg DCCP_WARN DCCP_CRIT DCCP_PR_DEBUG LIMIT_NETDEBUG With some more researching I'm sure I'd find more printk wrappers. But I guess this should make some sort of point: using these wrappers get us closer to what Alan wants: consistent printk messages. Such that the life of kcolorls like wrappers get to the point that the life of user level debugging loggers can jump and shout in happiness for providing even nifty popup messages on modern desktops. As if the problem with modern desktops (or server consoles) was just that... gimme a way to configure wpa-psk on my brand new company notebook without having to resort to, ugh, command line assistance... Bluetooth without having to manually do service bluetooth start... - Arnaldo P.S.: I know that that is just in the making, dbus and a lot of other buzzwords that keep promising to solve these kinds of problems :-) - 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: NAK nettiquete (was Re: Re: [PATCH 0/2] Colored kernel output (run2)
On Oct 7 2007 17:23, Alan Cox wrote: - If you want to do pretty boot up you do it in X or frame buffer (which is going to get easier and easier with the X shift to kernel side video support) fb is slow. Feels like a 9600bps serial line. So fix your fb. There is enough information to cover 2D scrolling for most modern cards now. Let everyone have his own fun. The point isn't to put everyones fun into the kernel, or by now it would have become a steaming heap. We do have a steaming heap of obscure hardware drivers, actually. - 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/
