On Sat, Oct 06, 2007 at 09:48:20PM +0200, Ingo Molnar wrote:
> >
> > This is a "kernel messages color-l10n".
> >
> > * text code size, that cannot be zero if config option is not set;
>
> not really an issue. Changing the inline function to non-inline will get
> rid of most of the text cost. Embedded wont build in a console.
I'm trying to say "text size *and* config option is not set". That
have nothing to do with other text size reductions.
> > * 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?
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.
> The kernel console is one of the most important information channels of
> the kernel towards the user.
I'd say: towards hard OOPs-handling developer.
> 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.
But how to express opinion quickly and easily?
____
On Oct 6 2007 23:03, Oleg Verych wrote:
>>
>> (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.
>
>But how to express opinion quickly and easily?
You can't. I think that people will usually be interested _why_ you
voted for or against something (given the number of vote-submitters
does not go through the roof). That clearly won't fit into the subject,
and even if RFC822 allowed it, it's only displayed like 40 chars wide.
The submitter (me in this case) will even look at *all* mails, so as to
(1) address the NAKs and (2) address the hidden feature requests in
ACKs. :-)
On Sat, Oct 06, 2007 at 11:03:38PM +0200, Jan Engelhardt wrote:
>
> On Oct 6 2007 23:03, Oleg Verych wrote:
> >>
> >> (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.
> >
> >But how to express opinion quickly and easily?
>
> You can't. I think that people will usually be interested _why_ you
> voted for or against something
Do you really think so? Yes, there are possibly LKML bots, that will
read all messages in every thread. But i doubt they are humans.
I also think, that kill-files and kill-names are common tools of the LKML
readers. Thus, if someone sees my name with something like NAK in the
subject, then nothing to worry about: next, please. I just amazed how
inefficiently Subject, To, Cc headers are used. Everybody hurry through
huge mail backlogs with subjects in thread all like one.
Summary and keywords headers are not used, so why not to make
greping/selecting interesting/useful messages more efficient (and not
only for those who is in Cc list)?
Every mail/news reader displays To and Subject, so latter is last hope of
increasing of efficiency, even in small threads.
> (given the number of vote-submitters does not go through the roof).
> That clearly won't fit into the subject,
Sorry, i cannot see, what you are trying to say here. To place all
acks-by to subject? No, just to get summary in one particular reply.
> and even if RFC822 allowed it, it's only displayed like 40 chars wide.
> The submitter (me in this case) will even look at *all* mails, so as to
> (1) address the NAKs and (2) address the hidden feature requests in
> ACKs. :-)
____
* Oleg Verych <[email protected]> wrote:
> > > * completely useless, if properly implemented in userspace (with
> > > much reacher functionality).
> >
> > that's hogwash. No user-space runs during early bootup. (and yes i
> > want a color code at glance if something hangs in early bootup)
> > Nothing will color-code crashes, etc., etc. Control of the _kernel_
> > console by user-space is complete nonsense.
>
> If it is so important for major kernel developer like you, Ingo, then
> why there's no scrollback at first place? Why nothing like that was
> not implemented up until now?
even if it were true (which it isnt), that is not an argument against
including a useful change that exists now and that people are interested
in. (and yes, i have implemented kernel console improvements in the past
and vga scrollback support was in fact amongst one of my first ever
Linux kernel hacks so your comment is doubly wrong.)
> My first ever Linux hack was changing default console output color. I
> think it was seven years ago. I though, it was not serious, if nobody
> did that already (in the 2.2.14).
>
> Please, don't mix important stuff here. I know, what kernel console
> is.
your arguments are not an answer to my technical points, which i'll
repeat here:
| | [...] No user-space runs during early bootup. (and yes i want a
| | color code at glance if something hangs in early bootup) Nothing
| | will color-code crashes, etc., etc. Control of the _kernel_ console
| | by user-space is complete nonsense.
today's console code development goes in exactly the opposite direction:
we are including (formerly-) user-space console functionality in the
kernel so that we can for example print oopses even if we are in X mode.
> > this is nice and robust functionality that i personally welcome. The
> > default is not changed in any way.
> >
> > (btw., i corrected the subject line to remove the 'NAK'. Why do you
> > think you can 'NAK' a patch in this field?)
>
> I added comment (like this), so anyone can skip reading body, if
> headers are "Oleg Verych && NAK". In case if `NAK' have a magic
> meaning in the LKML, like control characters in the tty, i'm sorry.
yes, a 'NAK' has a particular meaning on lkml.
> But how to express opinion quickly and easily?
by writing a quick email expressing your opinion and waiting to see the
discussion play out itself ...
but it is very rude to 'NAK' a patch and it should only be done
carefully.
Ingo
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 developers/maintainers.
[0] not much, but something <ftp://flower.upol.cz/upload/debian.sh>
> Ingo
____
On Sun, 07 Oct 2007 13:10:35 +0200, Oleg Verych said:
> > > 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)?
The few times I've tried to NAK something outright, I've always tried to attach
plenty of technical explanation (usually of the form "Gaak, this oopses my
laptop") :), and cc: the relevant important_name, and hope they listen.
Fortunately, most of the time I can get away with a politely phrased variation of
"important_name would probably appreciate if you fixed XYZ and resubmitted"
comment.. ;)
> 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
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.
(changing Subject: back again, since Alan's returning to that topic...)
On Sun, 07 Oct 2007 16:12:22 BST, Alan Cox said:
> 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")
What would it take to have a pointer chain at a *well known* location or
similar magic so if a machine died, I'd be able to hook up a laptop with a
FireWire cable and do firescope magic to extract at least/just the dmesg buffer?
(Yes, I know this requires a 1394 port and some previous cooperation and setup
on the part of the 1394 driver. Assume I can get away with saying "add this
to your kernel command line to make debugging easier for me" ;)
(And yes, 5 years ago I'd have been wanting a "dump dmesg to floppy" patch,
but times move one and 1394 is more likely than a floppy now...)
* 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
> >- 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.
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).
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 :-)
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.
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.
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
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.
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.
____
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.
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,
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.
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.
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.
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
On Sun, Oct 07, 2007 at 10:04:44PM +0200, 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.
In fact mc config (ini) section is a better way.
I use default blue (which is very annoying) for root user, to be aware of
possible results. Otherwise i use black background:
[Colors]
color_terminals=linux,xterm
base_color=normal=lightgray,black:marked=magenta,black:executable=green,black:directory=lightgray,black:editnormal=green,black:editbold=red,black
The most exiting event recently was, that `lynx` in debian got updated, so
it displays much more colors for HTML formatting now. I'm happy.
____
On Oct 7 2007 22:50, Oleg Verych wrote:
>
>In fact mc config (ini) section is a better way.
Yes, for the default colors. But /usr/share/mc/syntax/ specifies
more of them.
>I use default blue (which is very annoying)
If blue were annoying, it would not be the default Windows background
(since Windows 2000). Then again, it's personal preference, so I suppose
you have a red/green desktop wallpaper for X11?
>The most exiting event recently was, that `lynx` in debian got updated, so
>it displays much more colors for HTML formatting now. I'm happy.
lynx. Update. Ha. Get w3m. Seriously. :)
* 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
* 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
> 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
On Sun, Oct 07, 2007 at 10:43:46PM +0200, Jan Engelhardt wrote:
>
> On Oct 7 2007 22:50, Oleg Verych wrote:
> >
> >In fact mc config (ini) section is a better way.
>
> Yes, for the default colors. But /usr/share/mc/syntax/ specifies
> more of them.
Syntax highlighting, OK.
Kind of funny thing with it. One for shell in `mcedit` is much nicer, but
`emacs` is more powerful as editor(R). But both have highlighting
problems with non trivial scripts (quoiting, data here, etc). I don't
know if it will ever be fixed :).
Comprehensive highlighting of contents of diffs (or even _patched_
sources) is XXII century feature.
Anyway if anybody have anything to look onto, like more Linux C types,
bogus coding style highlighting, i'll be glad to test. And any
emacs hacks, that gurus are using will be very appreciated.
[0] emacs setup and fontlocking <ftp://flower.upol.cz/emacs/>
> >I use default blue (which is very annoying)
>
> If blue were annoying, it would not be the default Windows background
> (since Windows 2000). Then again, it's personal preference,
Emacs have black background by default. I changed foreground to green,
and it is much nicer for long runs. Blue (or any bright) background
isn't comfortable, i think.
> so I suppose you have a red/green desktop wallpaper for X11?
Black background mostly. If you know classic blackbox wm (version <=
0.62), then Rancor(80%) and Artwiz(20%) my all time styles. But i use
no X for quite some time now.
____
On Oct 8 2007 00:18, Oleg Verych wrote:
>
>Kind of funny thing with it. One for shell in `mcedit` is much nicer, but
>`emacs` is more powerful as editor(R). But both have highlighting
>problems with non trivial scripts (quoiting, data here, etc). I don't
>know if it will ever be fixed :).
No, it will never get fixed. I use two editors on a day-to-day basis,
and that is mcedit and joe. No fixed rule on which to use. It goes as
far that I have the same syntax highlighting (almost) on both.
Because one thing in one editor is cumbersome in the other.
Perhaps if there was one editor with the hotkeys of *both* (yes,
means duplicates), maybe then I'd be satisfied.
>Emacs have black background by default. I changed foreground to green,
>and it is much nicer for long runs. Blue (or any bright) background
>isn't comfortable, i think.
Actually, blue is perceived as one of the darkest colors by the human
eye. There is a reason that the RGB -> grayscale transformation uses
the following weighting: r=76 g=154 b=26.
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.
____
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.
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.
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.
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.
> 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)
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.
____
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.
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.
On Mon, Oct 08, 2007 at 12:11:21AM +0200, Jan Engelhardt wrote:
>
> Actually, blue is perceived as one of the darkest colors by the human
> eye. There is a reason that the RGB -> grayscale transformation uses
> the following weighting: r=76 g=154 b=26.
But, not every video card reproduces blue in the same way, let
alone every monitor - somewhere I've got an old CRT monitor where
blue text was mostly unreadable (_too_dark_). For photo-editing,
I now use xgamma to get adequately-consistent results on whichever of
4 machines I'm using (one LCD monitor, with KVM switch) - the
settings for the individual machines are very different.
And, of course, people have different colour vision (and unless we
are labelled as colour-blind, we each regard our colour vision as
"normal"). So, what is perfectly acceptable for you on specific
hardware may be totally unusable for someone else.
Ken
--
das eine Mal als Trag?die, das andere Mal als Farce
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
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
On Mon, Oct 08, 2007 at 05:23:05AM +0200, Willy Tarreau wrote:
> On Sun, Oct 07, 2007 at 09:47:25PM +0200, Oleg Verych 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.
>
> But what I cannot understand is how you expect userspace to work while
> the lines are being displayed.
With `quiet' boot option no message bloat is flowing. I have on debian's
2.6.18 only two error message about PCI remaing error and if by buggy
grub didn't read initrd image correctly, so ungziping fails.
> 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.
OK. I don't know what somebody think it is like, let me show,
especially for our famous kernel developer.
In flower ftp upload adopted "init" script for initramfs can be found.
I took standard debian's and added my stuff on head.
With quiet option kernel (should) very quickly reach initramfs/init.
Even 4M gzipped image (14M unpacked) on my laptop loads pretty quickly.
All is nice looking and scrollable (a bit). I didn't tried to do
separate scrolling regions for info and errors, because back scrolling
would be dead. But if somebody will fix this kernel feature, things
can be done easily then. Or file backup can used instead, early dmesg
available as a side effect.
So, i let see colored messages even for very old kernels, if this head
is added to initramfs/init. If it doesn't work for you, let's make it
work!
(sh: `sleep` must not be from busybox, because it has no seconds
fractions, which is kind of stupid, but POSIX compatible. My proposition
about select() like tool for shell can be found in google:
'olecom select sh')
== Script makes basic fs setup: ==============================
#!/bin/sh
# NOTE: pipefs (in <2.6.2?) isn't up yet
set +e
test -e null || mknod null c 1 3
{
mkdir -m 0755 /dev
mkdir -m 1777 /tmp
mkdir -m 0555 /proc
cd /dev
mknod null c 1 3
mknod kmsg c 1 11
mknod tty c 5 0
mknod console c 5 1
} 2>null
umask 077
mount -t proc proc /proc
== then TERM=linux tty loglevel attributes setup: ============
DEF='\033[0m'
EMERG='\033[1;5;37;41m' # bold blink white fore- on red background
ALERT='\033[1;37;41m'
CRIT='\033[1;5;31;40m' # bold blink red on black
ERR='\033[1;31;40m'
WARN='\033[1;33;40m' # bold yellow,
NOTICE='\033[1;36;40m' # cyan
INFO='\033[1;32;40m' # green
DBG='\033[1;34;40m' # blue
q='\033[1;35m`'
b="\033[1;35m'"
== polling/printing daemon setup ================================
kttylog() {
# in case of rootfs change die
# (rerun manually in the end of the init script with new rootfs)
set -e
trap '
echo "reloading kttylogd, new pid=$!" >/dev/kmsg
exit
' EXIT HUP
while read -r LINE
do case "$LINE" in
'<0'*) COLOR=EMERG;;
'<1'*) COLOR=ALERT;;
'<2'*) COLOR=CRIT;;
'<3'*) COLOR=ERR;;
'<4'*) COLOR=WARN;;
'<5'*) COLOR=NOTICE;;
'<7'*) COLOR=DBG;;
esac
# turn name to value
eval 'printf "$'"${COLOR=INFO}"'"'
# print raw content
printf %s "${LINE#???}"
# finish line output
printf "$DEF\n\r"
done
}
== wait to see all "quiet" messages ==========================
printf "
After you've seen errors, even with $q\033[33mquiet$b$DEF option,
to see other (usual) printk() stuff and continue to boot,
please, hurry to press $q\033[0;1mEnter$b$DEF
"
fancy_read() {
TIMEOUT=7 # bash has seconds-only there, but we can have all,
# that (klibc's) `sleep' can (it has useful fractions, POSIX hasn't)
# Peter (hpa) did bash-incomatible change in klibc's `read`,
# added `-t', added with second fractions :(
# this functions is an example to show, that by means of `sh`
# it's possible to have *fancy* read (i.e. nice and flexible
POLLTIME=5 # tenths of seconds
TIMEOUT=${TIMEOUT}0
PROMPT="("
G=$((${#PROMPT} + 1))
PROMPT="$PROMPT$TIMEOUT): "
echo -n "$PROMPT"
exec 4<&0 # /dev/tty isn't working early, thus do dup of stdin for `read' job
( read LAMER_LEVEL || echo "Read Error" ) <&4 &
exec 4<&-
INPUT_PID=$!
while /bin/sleep 0.$POLLTIME && test -e "/proc/$INPUT_PID/exe"
do
TIMEOUT=$((${TIMEOUT} - $POLLTIME))
if test "$TIMEOUT" -gt 0
then printf "\0337\033[${G}G$TIMEOUT): \0338"
else printf "\033[${G}Gtime is out)"
test -e "/proc/$INPUT_PID/exe" && kill $INPUT_PID
break
fi
done
}
fancy_read
unset fancy_read
== run printing daemon ==========================================
kttylog < /proc/kmsg >console &
KTTYLOG_PID=$!
cd /
== after flow of all pending messages, print this stuff==========
echo "<0>EMERG message (kmsg)..." >/dev/kmsg
echo "<1>ALERT message (kmsg)..." >/dev/kmsg
echo "<2>CRIT message (kmsg)..." >/dev/kmsg
echo "<3>ERR message (kmsg)..." >/dev/kmsg
echo "<4>WARN message (kmsg)..." >/dev/kmsg
echo "<5>NOTICE message (kmsg)..." >/dev/kmsg
echo "<6>INFO message (kmsg)..." >/dev/kmsg
echo "<7>DBG message (kmsg)..." >/dev/kmsg
echo "
interactive shell (type exit to continue)
" >/dev/kmsg
== shell to have a bit of the rest =============================
sh -i
echo "Loading Debian..."
== continue booting ============================================
--- stuff ---
> Willy
>
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
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
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