Le 03/03/2023 à 21:29, Rainer Weikusat via Dng a écrit :
> 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.
>
    Even with this definition, the only thing the kernel cares is pid1,
/the process/, not the executable it actually runs, and this executable
can change over time and actually does change. In pretty much every
distro, the first init is run in an initramfs; then, when the mandatory
filesystems have been mounted, this first init /executes/ /usr/sbin/init
-- it actually performs a sequence of pivot_root() and execve(), by the
mean of an utility which can be pivot_root or switch_root.

    Later on, nothing prevents this program to /execute/ any other
program. As long as it remains pid1, it remains the one in charge to
reap orphan processes, the one which has a special management of
signals, and the one the kernel does not want to exit. Therefore, it is
only the /process/ with pdi 1 the kernel cares of.

--     Didier