On Monday 24 January 2011 22:38, Harald Becker wrote: > - if at start of getty:
yes > why is it required? as the tty should have been > closed and reopened before, the queues should already be empty. > So which > output get lost, exactly please. I don't know what output gets truncated. I assume it's kernel console output. > What is that flush/drain for ... except > that very old bug, that changing line setup fails on none empty buffers? Unfortunately, whoever added that flush forgot to add a detailed comment: commit 1fca558799350fb6caff97f55aa6d1237b08fccb Author: Robert Griebl <[email protected]> Date: Tue Jun 4 20:45:46 2002 +0000 Bigger patch for (partial) tinylogin integration - Made a new dir loginutils - Moved all applets from pwd_grp to loginutils - Added new applets su.c login.c to loginutils - Made a new dir libpwdgrp - Moved everything from pwd_grp/libpwd_grp there - Added shadow.c to libpwdgrp - Removed dir pwd_grp - Added usage strings for login and su to usage.h - Changed main Makefile to reflect the dir rearrangements [Parts of this patch may overlap with my other two patches] ... + /* + * Initial termio settings: 8-bit characters, raw-mode, blocking i/o. + * Special characters are set after we have read the login name; all + * reads will be done in raw mode anyway. Errors will be dealt with + * lateron. + */ +#ifdef __linux__ + /* flush input and output queues, important for modems! */ + (void) ioctl(0, TCFLSH, TCIOFLUSH); +#endif When I see that comment, I think: "Thanks for informing us that it is important. It would be awesome if we would also be informed WHY it is important..." > ... if at getty startup, a short delay of a second or so, wouldn't be > that bad, as it is the tty process startup. That's how I see it too. > That would even be a good > idea, as old init processes sometimes delayed spawning of new (getty) > processes for several seconds (resulting in tty close - delay - open) > ... which isn't done by busybox init (as far as I noted some time ago) I believe it _is_ done: /* Now run the looping stuff for the rest of forever. */ while (1) { int maybe_WNOHANG; maybe_WNOHANG = check_delayed_sigs(); /* (Re)run the respawn/askfirst stuff */ run_actions(RESPAWN | ASKFIRST); maybe_WNOHANG |= check_delayed_sigs(); /* Don't consume all CPU time - sleep a bit */ ===========> sleep(1); maybe_WNOHANG |= check_delayed_sigs(); /* Wait for any child process(es) to exit. * * If check_delayed_sigs above reported that a signal * was caught, wait will be nonblocking. This ensures * that if SIGHUP has reloaded inittab, respawn and askfirst * actions will not be delayed until next child death. */ if (maybe_WNOHANG) maybe_WNOHANG = WNOHANG; while (1) { pid_t wpid; struct init_action *a; /* If signals happen _in_ the wait, they interrupt it, * bb_signals_recursive_norestart set them up that way */ wpid = waitpid(-1, NULL, maybe_WNOHANG); if (wpid <= 0) break; a = mark_terminated(wpid); if (a) { message(L_LOG, "process '%s' (pid %d) exited. " "Scheduling for restart.", a->command, wpid); } /* See if anyone else is waiting to be reaped */ maybe_WNOHANG = WNOHANG; } } /* while (1) */ -- vda _______________________________________________ busybox mailing list [email protected] http://lists.busybox.net/mailman/listinfo/busybox
