Autor: Didier Kryn Datum: To: dng Betreff: Re: [DNG] Runit init system discussed at GoLUG, Wednesday, 3/1/2023,
7pm Eastern Standard
Le 02/03/2023 à 16:37, Rainer Weikusat via Dng a écrit : > capercally.bleery670@??? writes:
>> On Wed, Mar 01, 2023 at 02:38:20PM -0500, Steve Litt wrote:
>>
>>>> A definition of init could be useful here: That's the one program the
>>>> kernel knows about[*]. After the kernel finished
>>>> booting, it creates a process and executes the init program. [**]
>>> Thanks Rainer!
>>>
>>> I inserted your definition into my presentation and attributed it to
>>> you. The presentation already had several other definitions, and yours
>>> adds the fact that PID1 is the only program the kernel knows about.
>> There's a bit of an ambiguity here. "Program" can (and in varying
>> contexts, does) mean:
>>
>> - an executable file (maybe including interpreted scripts)
>> - a process
> A program (file) is something whose filesystem location is a valid
> first argument to the execve system call. A process is a kernel
> abstraction for running programs.
Sorry but I will spread confusion, because the following question
arises: How could we name a predefined set of executable files which
overlay each other (execve) in the same process?
Init has various tasks to perform, which differ largely between
the different steps of the system lifetime. For the sake of
doing-one-thing-and-doing-it-well, Init can be made of (at least) 3
different executables: the first to initialize the system, the second to
just wait for the halt/reboot signals, and one to actuially manage halt
or reboot. The kernel execs the first of these "executables", then each
of them but the last execs the next one.
When an interpreter executes a script, it may invoque several
applications, generally creating temporary processes, but the real
program is the script. On the other hand, Laurent Bercot has written a
set of applications which execute a script while remaining the same
process, by execing each other; this is called execline -- IIUC. The
applications belong to a predefined set, but the real program is the scipt.
It seems actually complicated to define what a program is (~: A
"program" is something too general to be easily defined technically. A
process is a well defined thing provided it has a single thread. Let's
say that the kernel creates pid1 and let it exec some command given in
the kernel command-line. This *process* is then treated specially by the
kernel.