(one which strips trailing slash and one which does not)
wget: straighten out as a result of above change
text data bss dec hex filename
5056 1 0 5057 13c1 busybox.t4/networking/wget.o
5022 0 0 5022 139e busybox.t5/networking/wget.o
trylink: explain how to modify link and drastically decrease amount
of padding (unfortunately, needs hand editing ATM).
*: add ALIGN1 / ALIGN2 to global strings and arrays of bytes and shorts
size saving: 0.5k
correct_password: explain in detail why it is ok to use bb_banner
fsck_minix: make it print bb version, not it's own (outdated/irrelevant) one
Marginal size difference:
text data bss dec hex filename
679119 2700 15632 697451 aa46b busybox_old
679091 2700 15632 697423 aa44f busybox_unstripped
executable if we asked to exec someting with argv[0] == known_applet"
Use it in init. Also respect PATH in init, remove explicit "/sbin" etc
from exec. Patch by Gabriel L. Somlo <somlo@cmu.edu>
It is impossible to formulate sane ABI based on
size of ulong because it can be 32-bit or 64-bit.
Basically it means that you cannot portably use
more that 32 option chars in one call anyway...
Make it explicit.
bb_xx_msg will ever try to send output to syslog.
Add "select CONFIG_FEATURE_SYSLOG" to relevant applets.
This allows to omit syslog code if we do not have
any syslog-capable applets in the build.
init's argv[1], so if you append "single" to your kernel command line and
the kernel doesn't parse it, RUNLELEL=single.
Plus a few unrelated header cleanups while I was in the area...
http://www.opengroup.org/onlinepubs/009695399/functions/waitpid.html suggests
that we need not specify a status if we don't want, and we don't.
"If wait() or waitpid() return because the status of a child process is available, these functions shall return a value equal to the process ID of the child process. In this case, if the value of the argument stat_loc is not a null pointer, information shall be stored in the location pointed to by stat_loc. "
text data bss dec hex filename
5391 32 8 5431 1537 init/init.o.06
5379 32 8 5419 152b init/init.o
- add second argument to waitfor(*action,pid); if action==NULL then use pid tor
wait for. If an action was given, we wait for the action to finish just as
before. In run() remove second and third occurance of the same functionality
the waitfor() call now provides.
Adjust the former only caller of waitfor accordingly.
PS: Not using waitfor but creating a second function used a few bytes more than
simply extending and reusing waitfor.
text data bss dec hex filename
5426 32 8 5466 155a init/init.o.orig
5391 32 8 5431 1537 init/init.o
It makes busybox invoke the libselinux library function to load the binary
policy right at system start-up. It was successfully tested on a mini-SELinux
system. Note: requires recent libselinux. I'm using 1.28.
else is a kernel bug. Both 2.4 and 2.6 should get this right now. This
should fix the bug IraquiGeek is seeing (although killall still needs to
be fixed.)
The init applet will restart (re-exec) itsself when it
receives a SIGHUP. However, just before it enters its
main loop, it resets SIGHUP to either re-load the inittab
(or ignore it if no inittab is used). Thus preventing
the re-exec option from being triggerable.
This patch adds a signal handler for SIGQUIT for init that
always causes init to re-exec itsself (along with killing
anything else that might be still running).
Hello, all.
Busybox init does not handle removed inittab entry correctly.
# I'm sorry about my poor english, but you can find
# what I would like to say from patch, isn't it?
even if you apply this path,
when yoy try to change a command line option in inittab,
you have to do following steps.
1. remove old line from initrd
2. send HUP signal to init
3. kill old proces which is invoked from init.
4. append new line to inittab
5. send HUP signal to init, again
patch is against current CVS + last patch witch I send it last.
"kill -HUP 1" reloads inittab, and when I append one line to inittab
and send HUP signal two times, It will starts 2 process.
patch against current CVS is attached.
Hi!
I've created a patch to busybox' build system to allow building it in
separate tree in a manner similar to kbuild from kernel version 2.6.
That is, one runs command like
'make O=/build/some/where/for/specific/target/and/options'
and everything is built in this exact directory, provided that it exists.
I understand that applyingc such invasive changes during 'release
candidates' stage of development is at best unwise. So, i'm currently
asking for comments about this patch, starting from whether such thing
is needed at all to whether it coded properly.
'make check' should work now, and one make creates Makefile in build
directory, so one can run 'make' in build directory after that.
One possible caveat is that if we build in some directory other than
source one, the source directory should be 'distclean'ed first.
egor
On Sat, Jun 19, 2004 at 10:57:37PM +0200, Bastian Blank wrote:
> The following patch changes klogd to use openlog/syslog themself
> instead of calling syslog_msg which always calls the triple
> openlog/syslog/closelog.
Updated patch: get rid of syslog_msg entirely. Request from Erik Andersen.
Bastian
It looks like latest uClibc defines ARCH_HAS_MMU, but a few busybox files
test UCLIBC_HAS_MMU, resulting in vfork() getting called instead of
fork(), etc.
Patch below. Only tested for lash.
Cheers,
-Jamie
the busybox menuconfig triggered my "inacceptable number of spelling mistakes"
upper level, so I decided to make a patch ;-)
I also improved some wording to describe some things in a better way.
Many thanks for an incredible piece of software!
Andreas Mohr, random OSS developer
>I'm sure that no user process use old root now, but when run "umount
>/old_root", it says:
> umount: /old_root: Device or resource busy
>
>I have tried to remount /proc within the new root *after* chroot, but
>get the same result.
>
>
I found the problem, I said that no user process use old root when run
my scripts, but
I'm wrong, actually there is a '3' fd open the file
"/old_root/dev/console". By adding
debug message in init/init.c, I found the problem: when init restart(in
exec_signal()),
before open the new terminal device, there is still a file opened(I
don't know which file it is), so the
terminal device(stdin) get fd '1', and the first dup(0)(stdout) return
'2', the second(stderr) return '3'.
I attach a simple patch to solve this problem.
Here's a pretty crude patch to reload /etc/inittab when init receives a
SIGHUP. The mailing list archives weren't entirely clear on whether or
not it should already happen, but didn't appear to be.
The patch:
* Adds a new function, reload_signal() which just calls
parse_inittab() and run_actions(RESPAWN)
* Before entering the while (1) loop set up SIGHUP to call
reload_signal()
* Modify new_init_action to skip the action if the same command
already exists on the same terminal
This last bit means that changing already running entries is a bit
hairy as you can end up with, for example, two shells running on the
same virtual console. However, for solely adding/removing entries this patch
seems to work quite well.
Hello all,
This patch adds more "Help" text to the config system. Almost
all applets now have a help entry. Also, I cleaned up the spacing of
the existing text so that things are consistent. This patch is against
this morning's CVS.
Thomas Cameron
CEI Systems, Inc.
I've found a problem with job control when the init process is restarted.
If the system boots for the first time, I get job control on a serial terminal -
no problems. However, when I restart init by issuing "init -q", then the shell
no longer has job control.
I traced this a problem in console_init in the file init.c. What was happening
after the restart is that the first compare
if (ioctl(0, TIOCGSERIAL, &sr) == 0) {
...
} else if (ioctl(0, VT_GETSTATE, &vt) == 0) {
...
} else {
... // assume /dev/console
}
returned error and subsequently the code assumes /dev/console as the console,
which does not support job control.
Checking the errno after the first call showed that the system was complaining
about the file descriptor. This is probably because the previous init process
had closed all its file descriptors which the new init process had inherited.
