036585a911
FEATURE_GETOPT_LONG made dependent on LONG_OPTS. The folloving options are removed, now LONG_OPTS enables long options for affected applets: FEATURE_ENV_LONG_OPTIONS FEATURE_EXPAND_LONG_OPTIONS FEATURE_UNEXPAND_LONG_OPTIONS FEATURE_MKDIR_LONG_OPTIONS FEATURE_MV_LONG_OPTIONS FEATURE_RMDIR_LONG_OPTIONS FEATURE_ADDGROUP_LONG_OPTIONS FEATURE_ADDUSER_LONG_OPTIONS FEATURE_HWCLOCK_LONG_OPTIONS FEATURE_NSENTER_LONG_OPTS FEATURE_CHCON_LONG_OPTIONS FEATURE_RUNCON_LONG_OPTIONS They either had a small number of long options, or their long options are essential. Example: upstream addgroup and adduser have ONLY longopts, we should probably go further and get rid of non-standard short options. To this end, make addgroup and adduser "select LONG_OPTS". We had this breakage caused by us even in our own package! #if ENABLE_LONG_OPTS || !ENABLE_ADDGROUP /* We try to use --gid, not -g, because "standard" addgroup * has no short option -g, it has only long --gid. */ argv[1] = (char*)"--gid"; #else /* Breaks if system in fact does NOT use busybox addgroup */ argv[1] = (char*)"-g"; #endif xargs: its lone longopt no longer depends on DESKTOP, only on LONG_OPTS. hwclock TODO: get rid of incompatible -t, -l aliases to --systz, --localtime Shorten help texts by omitting long option when short opt alternative exists. Reduction of size comes from the fact that store of an immediate (an address of longopts) to a fixed address (global variable) is a longer insn than pushing that immediate or passing it in a register. This effect is CPU-agnostic. function old new delta getopt32 1350 22 -1328 vgetopt32 - 1318 +1318 getopt32long - 24 +24 tftpd_main 562 567 +5 scan_recursive 376 380 +4 collect_cpu 545 546 +1 date_main 1096 1095 -1 hostname_main 262 259 -3 uname_main 259 255 -4 setpriv_main 362 358 -4 rmdir_main 191 187 -4 mv_main 562 558 -4 ipcalc_main 548 544 -4 ifenslave_main 641 637 -4 gzip_main 192 188 -4 gunzip_main 77 73 -4 fsfreeze_main 81 77 -4 flock_main 318 314 -4 deluser_main 337 333 -4 cp_main 374 370 -4 chown_main 175 171 -4 applet_long_options 4 - -4 xargs_main 894 889 -5 wget_main 2540 2535 -5 udhcpc_main 2767 2762 -5 touch_main 436 431 -5 tar_main 1014 1009 -5 start_stop_daemon_main 1033 1028 -5 sed_main 682 677 -5 script_main 1082 1077 -5 run_parts_main 330 325 -5 rtcwake_main 459 454 -5 od_main 2169 2164 -5 nl_main 201 196 -5 modprobe_main 773 768 -5 mkdir_main 160 155 -5 ls_main 568 563 -5 install_main 773 768 -5 hwclock_main 411 406 -5 getopt_main 622 617 -5 fstrim_main 256 251 -5 env_main 198 193 -5 dumpleases_main 635 630 -5 dpkg_main 3991 3986 -5 diff_main 1355 1350 -5 cryptpw_main 233 228 -5 cpio_main 593 588 -5 conspy_main 1135 1130 -5 chpasswd_main 313 308 -5 adduser_main 887 882 -5 addgroup_main 416 411 -5 ftpgetput_main 351 345 -6 get_terminal_width_height 242 234 -8 expand_main 690 680 -10 static.expand_longopts 18 - -18 static.unexpand_longopts 27 - -27 mkdir_longopts 28 - -28 env_longopts 30 - -30 static.ifenslave_longopts 34 - -34 mv_longopts 46 - -46 static.rmdir_longopts 48 - -48 packed_usage 31739 31687 -52 ------------------------------------------------------------------------------ (add/remove: 2/8 grow/shrink: 3/49 up/down: 1352/-1840) Total: -488 bytes text data bss dec hex filename 915681 485 6880 923046 e15a6 busybox_old 915428 485 6876 922789 e14a5 busybox_unstripped Signed-off-by: Denys Vlasenko <vda.linux@googlemail.com> |
||
---|---|---|
.. | ||
add-remove-shell.c | ||
addgroup.c | ||
adduser.c | ||
chpasswd.c | ||
Config.src | ||
cryptpw.c | ||
deluser.c | ||
getty.c | ||
Kbuild.src | ||
login.c | ||
passwd.c | ||
README | ||
su.c | ||
sulogin.c | ||
vlock.c |
Getty ??? Should getty open tty with or without O_NONBLOCK? For serial lines, it means "should getty wait for Carrier Detect pin?" I checked other getties: - agetty always uses O_NONBLOCK - mgetty uses O_NONBLOCK unless run with -b, or as "getty" ??? If we decided to use O_NONBLOCK (perhaps optionally with -b), when getty should send -I INITSTR data to tty? After open succeeds? What if we also want to initialize *modem* with some AT commands? ??? Should we check/create /var/lock/LCK..ttyPFX lockfiles? ??? mgetty opens tty but does NOT lock it, then waits for input via select/poll, and when input is available, it checks lock file. If it exists, mgetty exits (it assumes someone else uses the line). If no, it creates the file (lock the tty). Sounds like a good algorithm to use if we are called with -w... Getty should establish a new session and process group, and ensure that tty is a ctty. ??? Should getty ensure that other processes which might have opened fds to this tty be disconnected? agetty has a -R option which makes agetty call vhangup() after tty is opened. (Then agetty opens it again, since it probably vhangup'ed its own fd too). Getty should leave the tty in approximately the same state as "stty sane" before it execs login program. Minor things we do conditionally are: c_iflag |= ICRNL; // if '\r' was used to end username ??? mgetty uses per-tty file to ignore connects, /etc/nologin.ttyxx - is it useful? It should be possible to run "getty 0 -" from a shell prompt. [This currently doesn't work from interactive shell since setsid() fails in process group leader. The workaround is to run it as a child of something. sh -c 'getty - 0; true' usually works. Should we fix this?] It should leave tty in a sane state when it exits (Ctrl-D, -t SEC timeout): echo should be on, speed, control chars properly set, etc. (However, it can't restore ctty. The symptom is that "</dev/tty" fails in the parent shell after getty exits: /dev/tty can't be opened). Getty should write LOGIN_PROCESS utmp record before it starts waiting for username to be entered. Login Login should not try to set up tty parameters - apart from switching echo off while entering password, and switching it back on after. Login should not leave "echo off" state when it times out reading password or otherwise terminates (Ctrl-C, Ctrl-D etc). ??? Should login establish a new session and/or process group, and ensure that tty is a ctty? Without this, running login directly (not via getty) from e.g. initscript will usually result with a login session without ctty and without session/pgrp properly created... It should be possible to run "login [USER]" from a shell prompt, and it should work (not block/die/error out). Similarly to getty, it should leave tty in the sane state when it exits. ??? Should login write LOGIN_PROCESS utmp record before it starts waiting for username/password to be entered? Login should write USER_PROCESS utmp record just before it is about to exec user's shell.