WelcomeWelcome | FAQFAQ | DownloadsDownloads | WikiWiki

Author Topic: Busybox some patches with -p1 and others with -p0  (Read 2654 times)

Offline Roberto A. Foglietta

  • Full Member
  • ***
  • Posts: 212
    • personal home page
Busybox some patches with -p1 and others with -p0
« 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

Offline Roberto A. Foglietta

  • Full Member
  • ***
  • Posts: 212
    • personal home page
Re: Busybox some patches with -p1 and others with -p0
« Reply #1 on: August 11, 2021, 05:27:47 PM »

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 10957
Re: Busybox some patches with -p1 and others with -p0
« Reply #2 on: August 11, 2021, 11:37:14 PM »
It broke extension mounting because we do not use devtmpfs.
The only barriers that can stop you are the ones you create yourself.

Offline Roberto A. Foglietta

  • Full Member
  • ***
  • Posts: 212
    • personal home page
Re: Busybox some patches with -p1 and others with -p0
« Reply #3 on: August 12, 2021, 07:33:54 AM »
It broke extension mounting because we do not use devtmpfs.

Why you do not compile the kernel with devtmpfs support?

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 10957
Re: Busybox some patches with -p1 and others with -p0
« Reply #4 on: August 12, 2021, 08:40:41 AM »
Because it requires a newer udev, which brings more size with no benefits.
The only barriers that can stop you are the ones you create yourself.

Offline Roberto A. Foglietta

  • Full Member
  • ***
  • Posts: 212
    • personal home page
Re: Busybox some patches with -p1 and others with -p0
« Reply #5 on: August 12, 2021, 03:04:29 PM »
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.

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 10957
Re: Busybox some patches with -p1 and others with -p0
« Reply #6 on: August 12, 2021, 10:41:26 PM »
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 only barriers that can stop you are the ones you create yourself.

Offline Roberto A. Foglietta

  • Full Member
  • ***
  • Posts: 212
    • personal home page
Re: Busybox some patches with -p1 and others with -p0
« Reply #7 on: August 13, 2021, 06:05:10 AM »
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. ;-)

Offline curaga

  • Administrator
  • Hero Member
  • *****
  • Posts: 10957
Re: Busybox some patches with -p1 and others with -p0
« Reply #8 on: August 13, 2021, 09:38:33 AM »
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.
The only barriers that can stop you are the ones you create yourself.

Offline Roberto A. Foglietta

  • Full Member
  • ***
  • Posts: 212
    • personal home page
Re: Busybox some patches with -p1 and others with -p0
« Reply #9 on: August 13, 2021, 11:42:47 AM »
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
« Last Edit: August 13, 2021, 11:48:16 AM by Roberto A. Foglietta »