Busybox some patches with -p1 and others with -p0

[Roberto A. Foglietta]

Hi all,

 in this place and also in x86_64 and probably other architectures as well there is a problem

 http://tinycorelinux.net/12.x/x86/release/src/busybox/

 Four patches require -p1 while the last two requires -p0 but this is not very script friendly.

 In attachment the two patches converted in -p1

 I hope this helps,
-R

[Roberto A. Foglietta]

Dear all, just a question about a patch you applied for busybox

http://tinycorelinux.net/12.x/x86/release/src/busybox/busybox-1.33.0_skip-loop-control.patch

http://manpages.ubuntu.com/manpages/xenial/man4/loop.4.html

why do you avoid the loop-control?

[curaga]

It broke extension mounting because we do not use devtmpfs.

[Roberto A. Foglietta]

It broke extension mounting because we do not use devtmpfs.

Why you do not compile the kernel with devtmpfs support?

[curaga]

Because it requires a newer udev, which brings more size with no benefits.

[Roberto A. Foglietta]

Because it requires a newer udev, which brings more size with no benefits.

I see the point.

I suggest to use this patch in attachment instead of busybox-1.33.0_skip-loop-control.patch
The result is the same in TC but it is a general approach to the issue.
It checks for devtmpfs before skipping the loop-control.

[curaga]

Thank you, but if we're carrying a custom patch, the current one is faster. There is no TC env that might have devtmpfs.

[Roberto A. Foglietta]

the current one is faster.

I used a static variable to save the state of the first try.
Because busybox is running as shell every time a command is called, it uses the stored value.
It does a try only when the shell start by scratch which it does not happen often, AFAIK.
Thus, it is not slower but more general. ;-)

[curaga]

Sorry, that is wrong. Nothing is remembered because mount is a one-shot command, and even when running in a bb shell, it is not a nofork/noexec command that could remember global state.

[Roberto A. Foglietta]

Sorry, that is wrong. Nothing is remembered because mount is a one-shot command, and even when running in a bb shell, it is not a nofork/noexec command that could remember global state.

You are right, so I took the time spent in checking the devtmpfs: the maximum took is 253 uS.
It takes 1000 for having a couple of hundreds millisecond. Half a million for having 1 second delay.

Moreover, consider that I running it into a qemu virtual machine running into virtual box virtual machine.
For this reason it works 4 times slower than on real hardware. A real old-fashion x86 machine!

So, I can understand that is not useful for TC but it is not a bloating or a slowing issue. ;-)
If you like to check by yourself, I am attaching the code to take the time in nanoseconds.

Code: [Select]

[5.18] Loading TCZ archives: 101065 ns bash.tcz: OK 73887 ns bzip2-lib.tcz: OK 152215 ns dosfstools.tcz: OK 126242 ns dropbear.tcz: OK 252869 ns e2fsprogs.tcz: OK 68052 ns file.tcz: OK 75176 ns fuse.tcz: OK 80557 ns gnupg.tcz: OK 133072 ns kmaps.tcz: OK 124966 ns libassuan.tcz: OK 92610 ns libgcrypt.tcz: OK 112147 ns libgpg-error.tcz: OK 69304 ns liblzma.tcz: OK 69669 ns ncursesw.tcz: OK 95437 ns ntfs-3g.tcz: OK 87714 ns ntfsprogs.tcz: OK 207836 ns raid-dm-5.10.3-tinycore64.tcz: OK 98041 ns readline.tcz: OK 74194 ns sqlite3.tcz: OK