On 30/4/21 6:13 am, toybox-requ...@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
_______________________________________________
Toybox mailing list
Toybox@lists.landley.net
http://lists.landley.net/listinfo.cgi/toybox-landley.net
