On 11/7/2018 9:18 AM, Kang-Che Sung wrote:
On Wed, Nov 7, 2018 at 9:54 PM Tito wrote:
this embedded scripts patch looks like "featuritis" at its best to me.
It is adding complexity for solving what problem exactly:
avoiding to copy the scripts manually to the new system or to
the new firmware image?
I see one advantage of embedding scripts into busybox binary:
compression. The script could remain compressed in a firmware or
read-only image, saving space, and is useful for users who build
busybox only to run a specific script (installation, embedded
system startup, or something else non-trivial).
I think it's okay for that use case.
IMHO squashfs is a better option all around. The main use case I
imagine is that you want a recovery shell to live alongside a regular
system image, and have the embedded scripts only available when running
busybox sh, and save some integration work of mounting the rest of the
recovery file tree at the appropriate places. For example, if your
/etc/profile is only valid for bash, then if you want to run busybox ash
on that system it would help to have /etc/profile load magically from
within busybox.
The main downside I see is that it violates the Principle of Least
Astonishment.
One side effect I fear will derive from this patch is that
users which would be capable of sending patches for bugs
they find in bb will resort to simply scrap the applet and add
an embedded script as it is faster.
I disagree. Embedded script always has an overhead of starting a shell
interpreter, although I acknowledge the size advantage the script can
provide, as long as many coreutils are present in that environment.
The script won't worth embedding if you don't intend to build a shell or
coreutils in busybox.
It sounds like not just the overhead of the interpreter, but also the
overhead of decompressing them on each execution.
But, there are lots of standard unix tools which are seldom-used and
don't have much performance requirement, and if they can be implemented
as a shell script half the size of the comparable machine code, then
that makes sense.
-Mike
_______________________________________________
busybox mailing list
busybox@busybox.net
http://lists.busybox.net/mailman/listinfo/busybox
