echo Currently in gcc envirment, type \'musl\' to switch to musl.
musl() {
	export CC="$HOME/musl/bin/musl-gcc"
	export PATH="$HOME/musl/bin:$PATH"
	alias ld.so='$HOME/musl/lib/ld-musl-x86_64.so.1'
	alias ldd='ld.so --list'
	echo Done setting musl environment, use \'musl-gcc\' instead of \'gcc\'.
	unset -f musl
}

Only need to modify ldso/dynlink.c's load_library() function: 1. change char buf[2*NAME_MAX+2]; to char buf[PATH_MAX + NAME_MAX + 2] = {0}; because I need more space to calculate path; 2. after variable declaration and before if (!*name) {, add const char *sep = strrchr(name, '/'); if (sep) name = sep + 1;, yes, even shared library path is absolute, I'll remove directory, only keep filename; 3. comment following code:

if (strchr(name, '/')) {
    pathname = name;
    fd = open(name, O_RDONLY|O_CLOEXEC);
} else {
    ...
}

change to:

for (p = head->next; p; p = p->next) {
    if (p->shortname && !strcmp(p->shortname, name))
        return p;
}
if (strlen(name) > NAME_MAX) return 0;
fd = -1;
/* app's directory */
if (head->name && (sep = strrchr(head->name, '/'))) {
    size_t len = (size_t)(ptrdiff_t)(sep - head->name);
    if (len > PATH_MAX) return 0;
    memcpy(buf, head->name, len);
    buf[len] = '/';
    strcpy(buf + len + 1, name);
} else {
    strcpy(buf, name);
}
fd = open(buf, O_RDONLY|O_CLOEXEC);
/* PATH */
if (fd < 0) {
    const char *path = getenv("PATH");
    if (path && *path) fd = path_open(name, path, buf, sizeof buf);
}
pathname = buf;

Rebuild musl by running make && make install, and create hello.h hello.c hello-lib.c as following to do test.

#ifndef __HELLO_H__
#define __HELLO_H__
const char *greetings();
#endif

#include "hello.h"
#include <stdio.h>
int main(void) {
    puts(greetings());
    return 0;
}

#include "hello.h" 
const char *greetings() {
    return "Hello";
}

Test script is:

#!/bin/sh
# bash script won't read .bashrc 
ldd() {
    "$HOME/musl/lib/ld-musl-x86_64.so.1" --list "$@"
}
musl-gcc hello.c hello-lib.c -static -o hello-static
musl-gcc hello-lib.c -shared -o foo/hello-lib.so
musl-gcc hello.c foo/hello-lib.so -o hello-dynamic
export PATH=$(cd $(dirname $0); pwd)/foo:$PATH
echo $PATH
./hello-dynamic
ldd hello-dynamic

Now everything has almost been portable, except one: PT_INTERP, which is defined in dynamic linked executable's head, and read by kernel to determine to pass to which dynamic loader. It is static path, most evil one. Nix's developers asked to support $ORIGIN, but I think it's already weird. Why static exe is loaded by kernel but dynamic is passed to external loader? Why they can't be all handled by kernel, or all handled by loader? This does not conform to layering principle of general architectural design. It is hard to change everything, but I found simplest way, just add ld= kernel parameter to override PT_INTERP.

Open fs/binfmt_elf.c, before function implementation load_elf_binary(), add:

static char elf_ld_path[PATH_MAX];
static int __init elf_ld_setup(char *str)
{
    if (!str || !*str)
        return 0;

    if (strlcpy(elf_ld_path, str, sizeof(elf_ld_path)) >=
        sizeof(elf_ld_path))
        return 0;

    return 1;
}
__setup("ld=", elf_ld_setup);

And inside load_elf_binary(), change interpreter = open_exec(elf_interpreter); to interpreter = open_exec(elf_ld_path[0] ? elf_ld_path : elf_interpreter);.

Note: it only takes effect when builtin, not module. But that's enough, anyway my kernel disables modules, because they may involve problems about file paths.

Rebuild kernel by running make.

Dynamically rebuild init: musl-gcc -o bin/init src/init.c.

Copy needed files, including kernel, $HOME/musl/lib/libc.so and init, and add kernel parameter ld=/libc.so, command for making raw image is just like this: bin\raw -o bin\output.raw -c "root=/dev/sda rw init=/init ld=/libc.so" bin\bzImage bin\init bin\libc.so, also you can find it in start.js.

Now boot vm. Bingo!

I also hate initrd/initramdisk. Why can’t those amateurs just walk straight? Why do they insist on taking detours, adding extra steps to show off their so-called technical skills? Linux kernel is already bloated enough, does it really matter how much space few filesystem drivers take?

I like VirtualBox's small, stable, cross-platform. I want it to work like QEMU’s direct boot. After many research, feasible approach is: find simplest FAT16 filesystem which kernel can recognize (there’s also ROMFS, but not sure if it can write to hard disk partition). Then write kernel, init and bootcode into .raw format file, and convert to .vdi using VirtualBox tools.

There’s no existing FAT16 creation tool, so I wrote my own raw.c, super floppy format, only one partition, no master boot record. Since FAT has bootstrap section, it can boot properly. Write files sequentially into root directory on consecutive sectors, filenames strictly follow 8.3 convention, and are converted to uppercase. First file will be treated as kernel, loaded by bootcode. Bootcode boot.s is modified from famous https://sebastian-plotz.blogspot.com/ (included in kernel docs), compiled with nasm, then converted to text format with bin2c.c to include in raw.c. I wrote batch file make.bat to include above steps and generate raw.exe.

Next, compile kernel. On my Debian VM, first make allnoconfig or make tinyconfig to get minimal setup, then add support for tty/vt, msdos vfat, elf, etc. (I provided .config from 4.19.325 kernel. Why this version? Because I hate C++; I asked ChatGPT check latest GCC version that can be bootstrapped with pure C, which is 4.7.4, so I chose corresponding kernel version for later researches.)

Then, write simple init.c and compile it statically with gcc -static -o init init.c. Simplest is shown below, but I added some commands to make it looks like MS-DOS.

#include <unistd.h>
int main() {
    const char greetings[] = "Hello";
    write(STDOUT_FILENO, greetings, sizeof greetings);
    for(;;) pause();
    return 0;
}

With all materials ready, run raw -o output.raw bzImage init to generate image file, then run VBoxManage convertfromraw output.raw fat16.vdi --format VDI to convert, add it to 64-bit Linux VM, choose SATA/AHCI controller, boot, success. Steps above can be automated by start.js (based on https://github.com/shajunxing/sjx-script).

Preface

Linux has never followed KISS. To ease my OCD, it must be purified. Why they all use absolute path? Why can't I install two standalone versions /linux1 /linux2 ? In Windows, I can put portable apps everywhere, even C compiler is portable. Xorg, Wayland, GTK, QT... these split generates multiplicative associations between layers, disaster in software engineering. Some distributions such as Nix tried to solve problem, but sadly they became even more complex.

Don't build another layer to hide the complexity. Remove the complexity at its source.

To be honest, I also dislike Windows since XP. I imagine if it can be added from Validation OS by necessary parts: network, security, direct x, get rid of everything corresponding .net dwm, and add classic shell like Win95, that's enough. But I also realized putting too much effort in is meaningless.

In my mind, a Linux system that truly belongs to me should work like this:

1. Boot from a Live CD, use simple tools to partition and format the disk if necessary, extract the core system into a single directory, and set up the bootloader. That's it. No installation required.
2. User software comes as ZIP archives, too. Just extract and run. At most, you might need to add its directory to PATH. In most cases, you won't even need to do that.