[Toybox] Is: mkroot status? Was: are you on holls or has mail dumped?

[Rob Landley]

On 11/25/21 12:41 AM, scsijon wrote:
> OK, so you've concentrated on toybox code and not sent emails out.

Haven't had anything to say? I've been working on toysh (which nobody else cares
about until it's done), and mkroot and build plumbing.

I've been blogging about it, but my blog is sadly behind on getting edited and
posted. (I caught up recently to being ONLY a month behind on uploading. I
should catch up on that but I keep forgetting that other people care about my
strange hobby...)

> I was 
> worried if it had died and you hadn't realised.

I took this week off from $DAYJOB and I'm trying to get the long-delayed release
out, and have a huge todo pile I'm trimming down into something that can go into
a release.

(The reason I was quiet before monday is work draining the life out of me.)

> So I am wondering what the status of mkroot in toybox is as i'm 
> considering a build in a easyos container to replace my aborigonal sfs?

Currently in flux but I'd like to get it nailed down this week.

I fixed toysh on nommu targets and got $((math)) working again (I reversed the
priority order to start at 0 counting up instead of 15 counting down, and got
the comparisons wrong; + and - worked but the rest didn't. Oops. Test suite
wasn't properly testing the operators because I still haven't implement most of
them. I checked in a better test when I fixed it, that's at least checking the
priority order of the existing operators...)

What toysh _really_ needs to get people looking at it is command line
history/editing. (Yes that's just a gui thing, but "a bunch of plumbing works"
doesn't look finished to most people, and "it has an easy user interface" does.
*shrug*. Humans.) I have 90% of that GUI plumbing in the "watch" command
already, but haven't pulled the trigger until toysh is "good enough", which...
it's actually pretty close? Still lots of loos threads. It doesn't run
/usr/bin/ldd yet because the case/esac plumbing doesn't understand multiline
target) entries (again not hard, just one of many todo items)...

I recently ripped mkroot.sh a new one adding record-commands and trying to
clarify the control flow so I can make a youtube video explaining it. It's
probably mostly there now, but needs a lot more testing. (I broke some stuff in
the refactor, mostly back together now I think. It's aesthetically annoying to
make it larger because I liked saying I have a system builder in 250 lines of
bash, but I ALSO want to do a youtube video explaining it and the ~270 line
version is easier to read. Plus I keep adding features...)

I also got a little distracted poking at strace.c. And I still need to catch up
on Eric Molitor's FTP stuff, and finish the readlink fixes for all that broken
relative path stuff. And have like a bunch of other pending patches from people
like the giant pile of typo fixes from Samanta Natarro I've had open in a window
for MONTHS... (Not hard, it just changes a bunch of files that aren't clean in
my tree...)

With me, tabsplosion (https://xkcd.com/609) is a symptom of not having enough
time to close tabs. Right click open in new tab takes very little time, DEALING
with the todo item is work and tends to spin off MORE tabs...

> In EasyOS BarryK is plying with using pflask 
> (https://bkhome.org/news/201809/pflask-chroot-on-steroids.html) for his 
> container system and although it's a few years since any major work 
> happened to it, it actually doesn't seem to need much if anything, along 
> the lines of. 'don't play with it if it's not broken.'

I note that the phrase "chroot on steroids" was something I came up with for the
marketing spiel we gave to passers by for the OpenVZ table at Scale in 2011:

  https://landley.livejournal.com/53863.html

Nobody knew what a container was back then, so I explained it as a "chroot on
steroids".

You know how a VM fakes hardware to run a separate kernel with separate memory
with its own redundant page caches and such, passing I/O through fake devices
translating into packets and back out again for the host system, using device
drivers in the child OS and then reverse drivers in the VM to undo it again? And
to make it scale at ALL you need tickless kernels and balloon driver and so on
to try to get even 20 or 30 instances running on the same machine? Yeah, we
don't do any of that. Containers are basically just a chroot on steroids. Linux
always had each processes belong to a user, but a lot of stuff was unavoidably
shared. We gave the system the concept of groups of processes you can attach
extra accounting information to. In a container you can have your own PIDs and
your own network routing and your own mount tree and so on, so it LOOKS like a
separate system, but this isn't that much more expensive than a chroot, which
can easily scale to thousands of instances on a single machine, and that's why
containers are better. Your first process in the container THINKS its PID 1 and
THINKS it's running as root, so it can act as init and mount new filesystems and
so on, and when that container init task exits the whole container exits
including all the child processes it's spawned and all the mounts they've done,
cleaned up for you by the OS the same way you don't have to remember to close
all your filehandles when a process exits because the OS knows how to do it for
you because it knows what's yours. All we really did is made Linux nest, so all
that global system state is in a structure now and you can have more than one of
them. But there's still just one kernel running which has a global view of
shared resources, and can tell "this is a dozen mappings of the same file, it
only needs one copy of the physical memory to cache it" rather than one in each
VM. So a thousand continers can each run /bin/bash without eating a thousand
times as much memory, it's just one shared mapping.

(I had like 30 seconds to hook people so worked it out to a practiced patter. I
didn't write it down, but typing it out here some it's starting to come back.
Then I passed them to Kir Kolyshkin who did the "live migration between two
containers on separate machines" demo, which OpenVZ already had working and
which made it upstream into vanilla linux as criu a few years later... :)

I've been meaning to do proper container support in toybox since FOREVER, but my
todo list runneth over and alas, this still ain't my day job...

Rob