Didier Kryn <kryn@???> writes:
> 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?

Why do you think that's something special?

Historical excursion
--------------------
Initially, a UNIX process was a kernel abstraction
for an interactive user session. After booting was complete, the kernel
would create a process for each attached terminal, load the shell into
it an run it. Users would type in commands. The shell would parse these
commands, load the next program to run (first word of the command) over
itself and jumped to it. After this program exited, control was
transferred to some bootstrap code which again loaded the shell into the
process so that the user could enter the next command. The system had
neither execve nor fork system calls.

In this system, chdir was an external command which changed the working
directory of a process. As all program a user would run when using the
system would run in the same process, chdir could thus affect every
program run after it until the next chdir invocation (it had to become a
shell built-in when background tasks were later added to the system).
---------------------------
end of historical excursion

This paradigm is still useful today. It's at the core of a set of
process management tools written in C I've slowly been accumulating
since 2009. Eg, a program start command can look like this:

mad-daemon -n chdir /home/$USER chids -u $USER run-ca-mgmt-client

That's four generic utility programs (daemonize a process, change
directory, change user id) each of which does some changes to the
current proceess and then, execs the next program (run-ca-mgmt-client
being the start script for the actual application).

>      Init has various tasks to perform, which differ largely between
> the different steps of the system lifetime.

[...]

It actually doesn't, at least not in the sense you're using tasks. init
is a program the kernel whill start in a process created for this
purpose after its ready to respond to application requests (via system
calls). It has not system defined purpose as it's application, that is,
user code. It can do whatever a user wants it to do.

The first process is special in two respects (possibly in more, these
are the two I know about):

- orphaned processes get reparented to it after they terminated
- should it ever terminate, the kernel will panic

[...]

>     It seems actually complicated to define what a program is (~: A
> "program" is something too general to be easily defined technically.

>From the perspective of the system, a program (file) is something whose
pathname is a valid argument to the exeve system call.