[Toybox] init.c ? and oneit

[Rob Landley]

On 4/29/21 12:08 AM, scsijon wrote:
> Sorry about the slow response, making a small amount of $ to help to remain
> retired is my excuse.
> 
> On 20/4/21 5:19 pm, Rob Landley wrote:
>> Mostly I just haven't prioritized it? (You're the first to ask in a while, I
>> mostly just use oneit for my stuff, and android has its own giant init thing. I
>> plan to do it before 1.0, but it hasn't been a blocker.)
> 
> Ok, I don't know anything about oneit. Do you have, or can point me at any docs
> or something that tells me what needs to be changed to use it instead of init
> please?

There's "oneit --help" output?

It's not the same as init, it runs its command line as one child process (hence
the name) and then reboots when that child process exits.

The difference between oneit and init=/yourprogram directly (as PID 1) is:

1) that PID 1 has a bunch of signals blocked and /dev/console isn't a proper
controlling TTY. So if you "oneit /bin/toysh" then ctrl-c can work properly, and
without oneit it can't.

2) when PID 1 exits the kernel panics. Oneit instead reboots (or calls
halt/poweroff).

3) Unless pid 1 reaps zombies a lot all the orphaned processes that get
reparented to init accumulate.

The mkroot init script ends by calling oneit to launch the command shell (after
running the init script in PID 1 context):

https://github.com/landley/toybox/blob/master/scripts/mkroot.sh#L71

I'm not saying it's a complete replacement, I'm saying it's what's currently
available in toybox defconfig that I've been using which has prevented me
personally from _needing_ sysv init for my own systems. (I.E. why init.c is
still on the todo list rather than promoted already. Its absence is not blocking
_me_, and you're the first person to ask for it in a while...)

> Being a puppy man we run most things from root (no comments or flares on
> that please, we've dealt with enough of that in the past). Is there sourcecode
> for a standalone version of oneit available somewhere please?

A standalone version? Um, I wrote it in 2005 and a lot of those archives have
cycled off. (According to
http://lists.busybox.net/pipermail/busybox/2006-July/057182.html I posted it to
the User Mode Linux mailing list in december 2005, which no longer seems to exist.)

Ah, here you go:

https://github.com/landley/aboriginal/blob/92256d0c3773/sources/toys/oneit.c

> Preferably one
> that I can build and try with my existing systems, it may be just what is needed
> for a couple of other systems as well, if it's compatable (without major
> changes) as standalone?

It's not a sysv init, it's a minimal PID 1 manager for a single child process.

> yup, a whole bucket full of bloodworms, not just a small tub of fishing worms if
> you want to meet the complete init spec.

A) Ew?

B) what spec? Posix doesn't _mention_ init (or mount), which is one of my
persistent gripes about it.

> Includes timeslot and processor
> allocation configuration as well as levels assignment for logins linked to
> devices just to start with.

Um, are you referring to systemd? Which is not sysv init? (You can call taskset,
there's container infrastructure...)

> !NOT going there again, 3 months wasted many years
> ago, without any usefull code, just specs and flowcharts created, "^" wasn't happy.

Ah, I was confused because you're referring to something only you ever
experienced as if other people should know it.

> Not interested in systemd, never thought it would get as big as it has!

Big iron always grows exclusion tactics to make them impenetrable, so bald men
with special certifications halfway to retirement can charge 3 times as much to
work on them.

Mainframes were replaced by minicomputers, which were replaced by
microcomputers, which are being replaced by smartphones. The previous generation
always gets kicked up into the server space, and "the cloud" is just a marketing
term for PCs no longer being something you sit in front of to write code, but
instead being a machine you only interact with remotely THROUGH another device.

Conventional Linux is a Big Iron OS now, for containers running on big iron
server racks. If it's in a special climate controlled room behind locked doors
with extensive power and data cabling dedicated to housing bulk computing power,
it's big iron. Mainframe du jour.

The phone still needs to be weaned off cross-compiling form big iron. Working on it.

> I can
> see it's uses for a server, not for standalone workstation systems which is all
> I build and use nowadays, 50 years in computing next year, and my first year
> engineering tutor thought they were a passing 'flash-in-the-pan'.

38911 basic bytes free.

> scsijon

Rob