[Toybox] init.c ? and oneit

[scsijon]

On 30/4/21 6:13 am, toybox-request at lists.landley.net wrote:
> On 4/29/21 12:08 AM, scsijon wrote:
>> 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
thank you
>> 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.
Search under mutex and pthread, makes basically the same thing with a 
different name (IEEE Std 1003.1-2001 to start from), the mutex name came 
from mainframes from memory. And then there are the posix 'semaphores' 
if you want to go that way.
>> 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?
no
> 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 read 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.

No, there are earlier specs, that start from late last century, for init 
from unix, xenix (286/386/486), hp-ux (intel and RISC) and icon-ux 
(Motorolla) multi-processor minicomputers, all I was asked to and tried 
to do to start with was flowchart for parts that would work for the 
standalone system that we called workstations to get rid of the unneeded 
code to freeup memory, about half of it we thought, and add an 
auto-restart into it (didn't exist back then, it was all manually done 
unless it crashed). If you really want to see them, they should/maybe be 
on the appropriate archive sites, I do have a copy of a couple of the 
manuals in boxes somewhere in my archive storage room if they really 
need to resurface.

>> 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.

yup, usually works until the third re-assessment of funds, and then they 
are gone without any usefull output left behind, end of comment.


> 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.
just a modern equivalent of the 'dumb terminal'
> 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
meant computers, not systemd
>> were a passing 'flash-in-the-pan'.
> 38911 basic bytes free.
>
>> scsijon
> Rob
>
Also checkout 
https://support.sas.com/documentation/onlinedoc/ccompiler/doc700/html/lr2/index.htm, 
it's sas's version of the old posix docs, you might have to drill down 
for things, mount is zid-7937.htm.

scsijon