Commit graph SchOS/ports/fastfetch/Makefile
Author SHA1 Message Date
Nexoniarz
7d2eca8271 Faster ISO builds (69 s to 9 s) and a faster write.sh check
make iso recompiled the kernel and every command each time: iso and
ramroot wiped build/kernel, build/lib and build/cmd to make sure nothing
was compiled for the wrong RAMROOT setting. Only kernel/proc/proc.c and
kernel/dev/ramdisk.c read RAMDISK_ROOT, so only their objects go now.

Even then a no-op make iso took 69 s, because sysroot.stamp lists every
staged file with its mtime and two things re-copied files on every run:
the plain cp in etc-install (now cp -p) and fastfetch's install (now
install -C). A changed stamp rebuilds the Alpine root, the root image
and its zstd -19 compression. A no-op, and a one-file kernel change,
now take about 9 s.

write.sh read the stick back with a buffered cmp, slowly and possibly from
the page cache. It now reads 4 MB at a time with iflag=direct, which
checks the stick itself; --no-verify skips the check.

Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_015f73FesGZGYPkmDvUcj6QX
2026-10-25 19:28:03 +01:00
Nexoniarz
26bca020b6 licence: SchOS is GPL-2.0-or-later, no longer Apache-2.0
Nexoniarz is the sole author and SchOS was never published under
Apache-2.0, so this is a straight relicence. LICENSE is the FSF GPLv2 text,
every first-party SPDX header moves to GPL-2.0-or-later, and NOTICE,
README.md, docs/licensing.md and the site say so. projects/schfs-linux
follows the rest of the tree.

The GPL gives copyleft: a fork has to ship its source. It also lifts the
old "Linux drivers, never" rule, since GPL-2.0-only code combines with
GPL-2.0-or-later. "Or later" leaves room for GPLv3, but one binary still
has to pick one version, so docs/licensing.md now keeps Apache-2.0 and
GPLv3 code out of the kernel to keep Linux code possible there. BSD
4-clause code goes from "avoid" to "no", because the advertising clause
is GPL-incompatible.

LDLS still ships no .ko. That boundary is now project policy rather than
a legal requirement, and ldls.md, devices.md and licensing.md section 6
say so. refmod declares license=GPL, and ldls-check passes (27 checks).

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-10-22 08:48:45 +02:00
Nexoniarz
14f0e4d0e2 kernel: processes have an environment now, and zsh is the shell
Porting zsh found four defects in the kernel and one in the filesystem. None
of them were about zsh; all of them had been there the whole time.

**exec threw the environment away.** kernel/fs/exec.c wrote a single zero for
envp with the comment "(no environment)" -- not yet, but ever, for every
process. musl has been passing a perfectly good envp to execve (Linux 59, which
SchOS answers) and it was never read. So $TERM was unset, $PATH was whatever
each program invented, and a variable exported in a shell did not survive the
exec meant to carry it. exec() takes an envp, sys_exec reads argument three,
and schinit manifests grew an Environment key. The userland two-argument
exec(path, argv) stays as a wrapper that passes null explicitly -- the raw stub
is execve now, so a short caller cannot leave %rdx holding a stray pointer.

**Which overflowed the kernel stack.** Three pointer arrays, ~1.8 KB, on a
4096-byte stack, under exec -> loaduvm -> readi -> SchFS -> btree. Pid 1 went
down on the first exec. The canary caught it and named the process, which is
what it is for. They live in one kalloc'd page now.

**waitpid returned a bare -1** for both "no children" and "interrupted". musl
reads [-4095,-1] as -errno, so userspace saw EPERM; zsh printed "wait failed:
operation not permitted" and abandoned the rest of /etc/zsh/zshrc. -ECHILD and
-EINTR now. Third time a bare -1 has cost real time -- on a system with no
permission model, EPERM should be read as "a syscall returned -1".

**NVMA was 64.** musl's allocator takes a mapping per size class and does not
release them eagerly, so compinit ran out of slots and got -1, which is EPERM,
which malloc turns into NULL, which zsh reports as "fatal error: out of memory"
-- on a machine with 1000 MB free. 256 slots, and -ENOMEM.

**And a small write to SchFS costs 58 ms.** 200 writes to one open file take
11.75 s; the same to /dev/null take 0.14 s. That is the design stated at the
top of kmount.c -- one transaction group per operation, and a commit is two
flushes and an uberblock -- not a bug. But compdump writes its digest with
thousands of separate prints, so it takes minutes and looks like a hang.
compinit -D, which skips the dump, finishes in 3.6 s. This one is a decision
rather than a fix, so it is written up and left: /etc/zsh/zshrc keeps compinit
switched off and explains exactly why, with the measurements.

zsh runs as /bin/zsh and is the console shell. ZLE works -- arrow keys recall
history through terminfo, $COLUMNS reads the real 160 because TIOCGWINSZ was
fixed, colour and prompt expansion work, startup is 0.14 s. mksh keeps /bin/sh,
so schinit's no-jobs fallback is a different program from the one that could
have failed.

Also fixed while here: AT_CLKTCK was the literal 100 and is USER_HZ; the
extract rule in four ports could move a source tree inside itself when make
re-ran it, which is how zsh's configure came to write modfile=zsh-5.9/... into
config.modules and fail three steps later.

schfs-check passes. Full writeup in docs/history/kernel.md section 14.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VQ7Qx8E1q1M1bbCq8QLHS2
2026-09-12 23:26:50 +02:00
Nexoniarz
25ae0cfad9 ports: fastfetch, unpatched, and /etc/os-release so it can name us
fastfetch builds and runs on SchOS:

    OS: SchOS 0.1.0 x86_64
    Kernel: SchIFT 0.1.0
    Shell: sh          Terminal: schinit
    CPU: AMD Ryzen 7 5700G
    Memory: 11.94 MiB / 1016.93 MiB (1%)
    Disk (/): 4.64 MiB / 31.25 MiB (15%) - schfs

Here because it is a good acceptance test, not because SchOS needs a fetch
tool. It is ~410 C files somebody else wrote against Linux rather than against
our bugs, and running it exercises procfs, per-process directories, uname,
statfs, getpwuid, terminal detection by walking ppid, and an ANSI renderer all
at once -- which is the shape docs/plan/roadmap.md asked for when the previous
full-stack test was removed.

patches/ is empty and should stay that way. When fastfetch cannot detect
something the answer is to give the system the thing it is looking for, because
every other program looks for the same things. Its first run reported four
misses and they are being worked in that order:

    OS:       Could not detect OS          -> /etc/os-release, this commit
    Local IP: getifaddrs() failed          -> AF_NETLINK, next
    Host:     not set by O.E.M.            -> DMI in /sys, later
    Users:    Unable to detect any users   -> utmp, a userland convention

Four things the port needs that say nothing about SchOS, recorded in the
Makefile because each cost time to find:

  * Every ENABLE_* off. All 29 files calling dlopen are optional detection
    modules, and ENABLE_THREADS=OFF removes the single pthread_create -- which
    matters, because clone() here does not share an address space.
  * -isystem the compiler's own include dir. -nostdinc removes it too, and
    cpuid.h is emitted by the compiler with no musl equivalent.
  * Linux UAPI headers. musl ships none by design; a musl toolchain is normally
    paired with a separate linux-headers install.
  * libgcc on the link line, and libc twice -- libgcc pulls symbols back out of
    it (__popcountdi2), and a static link resolves left to right.

The toolchain settings are a CMake toolchain file rather than command-line
flags because CMAKE_*_INIT variables are only honoured when the cache is first
created. Reconfiguring an existing build directory ignores them silently.

Also rebuilt musl: build/ports/musl/prefix/bin/musl-gcc had the pre-move path
/home/nexoniarz/Documents/SchOS baked in by configure. The tree does not use
that wrapper -- it links with explicit -I/-L and crt objects -- so nothing was
broken by it, but it was stale and would mislead anyone who found it.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01VQ7Qx8E1q1M1bbCq8QLHS2
2026-09-12 19:08:53 +02:00