Tiny Core Linux
Tiny Core Base => TCB Talk => Topic started by: Roberto A. Foglietta on August 10, 2021, 05:50:53 AM
-
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
-
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?
-
It broke extension mounting because we do not use devtmpfs.
-
It broke extension mounting because we do not use devtmpfs.
Why you do not compile the kernel with devtmpfs support?
-
Because it requires a newer udev, which brings more size with no benefits.
-
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.
-
Thank you, but if we're carrying a custom patch, the current one is faster. There is no TC env that might have devtmpfs.
-
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. ;-)
-
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.
-
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.
[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