Re: iniramfs: smal bunch of small changes, getting rid of busybox STANDALONE_SHELL
On Sat, 19 Mar 2011, Michael Tokarev wrote:
> Hello.
>
> I'm trying to get rid of the ugly hack in busybox, which is
> activated by CONFIG_STANDALONE_SHELL in busybox configuration.
>
> What it does is: when you run its shell, ash, and run a command,
> such as dd or ls, and this command is provided by this busybox
> binary too, busybox executes itself to run this command, instead
> of trying to search it in $PATH as it's usually done.
>
> So effectively, all busybox commands becomes "shell builtins"
> like cd and echo (which is a built-in in most shells nowadays).
yes, this is known and wanted as busybox alternatives are quite
powerful, no? (at least more powerful than the smallish klibc ones)
> This "standalone shell" mode helps when you're working in some
> rescue environment where you want as less filesystem access as
> possible, so that just one (probably statically linked) executable
> is enough for everything. But such a usage case is very, well,
> special. In all other cases, such behavour is unexpected and
> confusing at best, and there's no good way to control which
> implementation of commands will be used if both busybox and
> an external binary provides the same command.
>
> So I'm trying to get rid of CONFIG_STANDALONE_SHELL in busybox,
> and initramfs is the only user of this feature currently.
I'm not conviced by the potential gain yet?
> The plan is to introduce (sym)links in initramfs pointing to
> busybox for all applets it provides, instead of just one
> executable which when executes itself.
>
> The patchset that follows is a bunch of very small changes for
> initramfs hooks that does the following:
>
> [001] don't move klibc's sh.shared to sh, link instead
> this is a tiny "optional" change, for consistency, so
> to say: when using symlinks it becomes more obvious which
> implementation is being used. Moreover, by not moving the
> original sh.shared we keep it even in case we'll use
> something else in the future.
>
> [002] don't warn about md-root need busybox: it doesn't anymore
> unrelated cleanup patch but it is in the same place I'll
> touch later: we believed mdadm needs busybox in initramfs,
> but it has been fixed long ago
>
> [003] don't copy busybox to sh, use proper name and symlink
>
> [004] rename hooks/busybox to hooks/zz-busybox to reorder it to be last hook
> this is in order to ensure that busybox hook will be run last,
> in order to "fill the gaps", -- to create links to busybox only
> for those commands which don't already exist in initramfs.
>
> [005] create links in initramfs to busybox with other names if not already exist
> the final thing
>
> The whole thing is also available in a git repository,
> git://git.corpit.ru/initramfs-tools.git in create-links-to-busybox
> branch.
>
> This series is based on maks/mkinitramfs_cp branch of initramfs
> git repository on alioth, since it requires commit 11e9453a29cbc1
> "mkinitramfs: copy over on build instead of using symlink tree",
> because it uses symlinks heavily.
>
> This is just one possible approach. Another approach will be
> to move whole hooks/busybox into busybox package, just like
> hooks/klibc actually, -- I'm not sure what kernel team prefers.
did newer busybox gain a switchroot utility?
thanks for your work and sorry if I misunderstood the purpose.
--
maks
Reply to: