[PATCH] Fix for getty console stair stepping

Rob Landley rob at landley.net
Thu Aug 24 20:09:49 UTC 2006


On Thursday 24 August 2006 12:04 pm, Antti Seppälä wrote:
> Well I'll be darned.
> I used mingetty when I tried the stair-steps and it worked like I
> expected (no stairs when doing the echo) so I assumed that this feature
> exists only in Busybox getty. Apparently I was wrong.

Well, I didn't say it was a _good_ behavior.  If mingetty is setting the flags 
differently, I don't have an objection to setting them the way mingetty does.

Looking at this code...  Barf.  Oh _JOY_.

find . -name "*.c" | xargs grep B9600
./libbb/speed_table.c:  {B9600, 9600},
./loginutils/getty.c:   {9600, B9600},

This argument look familiar to anybody?  Ouch...

Right, back on track.  Your patch sets c_oflag |= ONLCR, and line 722 also 
sets that bit in c_oflag.  That's guarded by cp->eol == CR, so when might 
that trigger?

Ok, so CR is CTL('M') (and the CTL macro is x ^ 0100) and the third entry in 
init_chardata (which is eol) is set to 13.

Hang on, back up:

The comparison value is an ascii character xored with an octal mask, and it's 
initialized to a decimal constant.

*shudder*  And according to the comments, this code has workarounds for linux 
0.12!  (Ok, deep breaths, deep breaths...  Moving on.)

Ok, the first _use_ of eol is in get_logname, line 629 where cp->eol is set to 
0...  Ok, is the code really that stupid?  Yes, yes it is.  Line 933 calls 
get_logname() with &charadata for cp, and on line 928 it set chardata = 
init_chardata.  (So why not just use init_charadata and be done with it?  Who 
wrote this?) 

Ahem:

AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAHHHHHHHHHHHHHHHHHHHHH!!!!!!!!!!!!!!!

You know, your patch is looking a lot better.  This isn't a very big applet 
but it's still needs the Crapectomy Of Doom and I really haven't got time 
right now.

> Anyway, the problem I am having is that if I want to launch a program
> when Busybox starts (e.g. from inittab with respawn -directive) and the
> application prints some startup or debug messages, they all will be
> stair-stepped after getty displays its login prompt.

So having "login:blah blah blah" with newlines afterwards is an improvement?  
You've still stomped the login: prompt...

> This is especially annoying if the application in question takes a
> little while to start (then getty has time to display its prompt and
> enable the "stair-stepping mode" before the app does its printing). If
> the application prints more than just a few lines of messages the output
> starts to look ugly and becomes very difficult to read.

Having two applications writing to the same tty over each other is likely to 
be ugly and difficult to read no matter what you do.

> Here are two lines to /etc/inittab which can be used to demonstrate the
> problem:
> 
> tty1::respawn:/sbin/getty 38400 tty1
> console::respawn:/bin/ping 127.0.0.1
> 
> 
> The application I am having most problems with is vdr, but I could
> imagine that this bothers other applications too.

You're doing something that's inherently broken after looking at the guts of 
getty.c I want to hit with a large rock anyway.  Try svn 15984.

Someday, I must clean up that whole thing.  But not today.  (One of my low 
priority tasks is auditing every busybox applet to see which ones need 
cleaning up and which ones are as good as they're going to get.  Considering 
that I often rewrite my own code multiple times before I'm happy with it, I 
suspect lots of them could use at least a little tightening up, but some more 
than others.  I dunno how to improve Miguel's uniq.c and I can't think of a 
better way to do mdev.c right now.  At the other extreme, in my ongoing 
mke2fs rewrite I've already replaced the whole e2fsprogs/uuid directory with 
one function that's something like 5 lines long...)

> I couldn't find a way of definitely fixing this without patching getty.
> If there is one, please let me know. :)

Well, in theory your init scripts should block until the various things
it's initting have all respawned, but since this is something that doesn't 
return and spits out asynchronous messages...

I take it that you can't run your init scripts on some _other_ console?  Or 
null?

Heck, why can't you launch this program from a script that does "program 
> /dev/null &"

Rob
-- 
Never bet against the cheap plastic solution.



More information about the busybox mailing list