08.04.2011 15:13, maximilian attems wrote: > On Sat, 19 Mar 2011, Michael Tokarev wrote: > [] >> + for link in $(${BUSYBOXDIR}/busybox --list-full 2>/dev/null); do >> + if [ ! -e "${DESTDIR}/$link" ]; then >> + [ -d "${DESTDIR}/${link%/*}" ] || mkdir -p >> "${DESTDIR}/${link%/*}" >> + ln -s /bin/busybox "${DESTDIR}/$link" >> + fi >> + done > > hmmmm > Care to explain the "beauty" of aboves compared to STANDALONE_SHELL > simplicity?
Yes, easily. The above way we can control which implementations are used. With CONFIG_STANDALONE_SHELL (which this whole thing tries to remove) if something is built into busybox it gets executed, no matter if the actual utility may be not from busybox. Consider for example module-init-tools - if I enable modprobe in busybox it will be used no matter which implementation you actually put into initramfs. It is also quite unnatural, so to say, - to provide an utility with some extended arguments/features and wonder why it fails when you run it in initramfs or whatever else busybox is used. Note the patch above creates links to busybox only when there's no alternative implementation already available in initramfs. In other words, it gives us a choice -- either use busybox implementation or whatever else user may have wish to use. Later on, continuing modprobe example again, we can make module-init-tools initramfs hook optional (conditional), controlled by presense of busybox and a configuration variable for example. That's the whole reason of the change - to make busybox to act as any other regular command does, and provide what a user actually expects. Thanks! /mjt -- To UNSUBSCRIBE, email to debian-kernel-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4d9f4ddf.2090...@msgid.tls.msk.ru