[Solved] proposal to clean up the tc-config script (maybe speed it up a little)

[nick65go]

proposal to clean up the tc-config script (maybe speed it up a little)

inside functions spreaded to be grouped (possible outside) and renamed with prefix "_"?
addUser()    -> _adduser()
wait4Server()    -> _wait4Server()
get_app()    -> _get_app()

obsoleted options in case, because modules build into kernel:

Code: [Select]

tc@box:~$ modinfo zram
modinfo: module '/lib/modules/5.4.3-tinycore64/zram' not found
tc@box:~$ modinfo zcache
modinfo: module '/lib/modules/5.4.3-tinycore64/zcache' not found
tc@box:~$ so option  [ -n "$NOZSWAP" ] is useless

Code: [Select]

tc@box:~$ figrep MemFree /proc/meminfo | awk '{print $2/4 "K"}'
sh: figrep: not found
tc@box:~$
pre-populate /etc/sysconfig/ (small size in ram); but will simplify default if/else statements:
default value for variable, pre-populates files:
LANG=C         -> /etc/sysconfig/language
TZ=""        -> /etc/sysconfig/timezone
USER="tc"    -> /etc/sysconfig/tcuser
null        -> /etc/sysconfig/superuser
null        -> /var/tmp/k5_skip
null        -> /etc/sysconfig/text
null        -> /etc/sysconfig/xonly
KEYMAP="us"    -> /etc/sysconfig/keymap
null        -> /etc/sysconfig/desktop
mydata        -> /etc/sysconfig/mydata

sample of bloat /fat code:

Code: [Select]

USER="tc"
...
if [ -n "$USER" ]; then
    if ! grep "$USER" /etc/passwd >/dev/null; then addUser; fi
else
    USER="tc"
fi
many action grouped together and in the back ground + in paralel?
/sbin/loadcpufreq 2>/dev/null &
/sbin/ifconfig lo 127.0.0.1 up && /sbin/route add 127.0.0.1 lo &
chmod u+s /bin/busybox.suid /usr/bin/sudo
modprobe -q squashfs 2>/dev/null

or similar:
[ -n "$XSETUP" ] && touch /tmp/xsetup_requested
[ -n "$XVESA" ]  && sed -i 's/1024x768x32/'"$XVESA"'/' /home/"$USER"/.xsession 2>/dev/null

I am not criticize, i just try to help for better auto-documenting the script.
Maybe will not be much speed gain (few seconds). I think other users had/have similar proposals.

[andyj]

Sounds like this http://forum.tinycorelinux.net/index.php/topic,23835.0.html again. Good luck.

[PDP-8]

I'm speaking carefully here - with all due respect.

If the proposed changes aren't adopted how about this:

Create a "remix" , which you guys obviously know how to do, and host it on github or somewhere else - announce it in the remaster-remix area.

So yeah, it's not a fork, but a working example of system improvements which may have a more demonstrable impact.

I'd fire up your stuff to check it out for sure.

.... skulking away ...

[Paul_123]

I guess my take on this is to measure the improvements you are asking to make. Make a simple change to tc-config so it tracks boot time.....and in what stages.  Boot your system and note the times.  Now make your changes, the boot again and compare the "real" boot times.

And be aware that Core-Scripts are used across other platforms other than x86/x86_64.  Although we did just create a branch for piCore.

As for nozswap comment.  The boot code still does function, its just the zram module is compiled into x86_64 kernel,  but it will keep the swap space from being used or not.

[curaga]

I don't see a "figrep" call anywhere...

[nick65go]

@curaga: sorry for "ifgrep". my mouse pointer random jumped into another aterm window/row and edited the tc-config by mistake/ live, without me note it.
@ paul_123: you are right about to measure the "improvment" pieces by pieces. I did it in the past (rudimentary) and it is about 2-7 seconds, depending on HDD speed, tc version (biger kernels now) etc. Lets say I boot the "laptop" 10 times/day, i ussualy just suspend it in RAM, but crappy battery can deplete in the mean time. So if I gain 2 seconds/boot, then is not worth the few hours spend testing the "improvments" which could break other CPU arhitecture not tested (arm vs. x86).The fact that you ask me to do the test myself, means that you already did some test, and you concluded that tc-config is in the best shape now  OK, just say it so clearly, no problem.

The proposal was more about better undestanding the documentation, audit the code again, because new version busybox bugs, what was OK in the past could be not OK now.

To make TC more modular as andyj said; i will "borrow" few ideas from him in my "remix".
I am not a programmer, so PDP-8 talk about git (public work) is no way for me. Forget about it.The problem with remix is that ussualy will be optimized for special purposes (QEMU virtual machine, UEFI only real laptop).

[nick65go]

Sounds like this http://forum.tinycorelinux.net/index.php/topic,23835.0.html again. Good luck.

looking at your work, i saw max 47 parameters in tc-config (a script of 17KB), to be read from /proc/cmdline and evaluated.
On average I assume any user use max 3-7 variables (lets say 5), because some options can be started from onboot (kmap, locale, windows-manager), others from /opt/bootsync.sh, ondemand, /home/user/.Xd, or others are mutually exclusive, such as:
- nodhcp/nfsmount*/tftplist*/httplist*/aoe*/ntpserver*
- xsetup/xvesa*/xonly/text
- base/showapps
So STATISTICALY (empiric): near no improvement in speed to grab (from RAM) and then parse (in RAM) only few variable (max. 5) commonly used day by day.
And for each variable usually is just a short action, such as export a value, load a kernel module.
Even we loose speed when is something interactive such as add/create user, wait for a USB, access the network.

It is all about cleaner infrastructure, as you said. And maybe better documentation as I said. If developers think is worth their time.

@forum moderator: you can mark this subject as [closed/solved]. thank you.

[Rich]

Hi nick65go

... sample of bloat /fat code:

Code: [Select]

USER="tc"
...
if [ -n "$USER" ]; then
    if ! grep "$USER" /etc/passwd >/dev/null; then addUser; fi
else
    USER="tc"
fi ...

At first glance, it might appear testing $USER for non-zero length is unnecessary since it is set to  "tc"  at the beginning of the script.
That would leave only this:

Code: [Select]

USER="tc"
...

if ! grep "$USER" /etc/passwd >/dev/null; then addUser; fiThat was my initial thought. Of course it was wrong. After $USER is set to  "tc",  it can be overridden with the  user=  boot code.
If someone enters this:

Code: [Select]

user=""or this

Code: [Select]

user=then $USER becomes a zero length (empty) string. So the only "bloat" is the  USER="tc"  at the beginning of the script.

... many action grouped together and in the back ground + in paralel?
/sbin/loadcpufreq 2>/dev/null &
/sbin/ifconfig lo 127.0.0.1 up && /sbin/route add 127.0.0.1 lo &
chmod u+s /bin/busybox.suid /usr/bin/sudo
modprobe -q squashfs 2>/dev/null

or similar:
[ -n "$XSETUP" ] && touch /tmp/xsetup_requested
[ -n "$XVESA" ]  && sed -i 's/1024x768x32/'"$XVESA"'/' /home/"$USER"/.xsession 2>/dev/null ...

There are 3 things (that I could think of) to keep in mind when deciding to background something
1. You want to make sure actions that depend on other actions are not backgrounded at the same time.
2. Backgrounding actions for speed is most effective when they have to wait for other slower operations anyway.
3. Backgrounding many actions capable of running at full speed could slow them down if the kernel needs to switch between them.