Executing programs

% After <#2485#> fork()<#2485#>ing, two copies of the same program are running. One of them usually <#2486#> exec()<#2486#>s another program. The <#2487#> exec()<#2487#> system call must locate the binary image of the executable file, load and run it. The word `load' doesn't necessarily mean ``copy in memory the binary image'', as \ supports demand loading. The \ implementation of <#2488#> exec()<#2488#> supports different binary formats. This is accomplished through the <#2489#> linux_binfmt<#2489#> structure, which embeds two pointers to functions---one to load the executable and the other to load the library, each binary format representing both the executable and the library. Loading of shared libraries is implemented in the same source file as <#2490#> exec()<#2490#> is, but let's stick to <#2491#> exec()<#2491#> itself. The \ systems provide the programmer with six flavors of the <#2492#> exec()<#2492#> function. All but one of them can be implemented as library functions, and the \ kernel implements <#2493#> sys_execve()<#2493#> alone. It performs quite a simple task: loading the head of the executable, and trying to execute it. If the first two bytes are ``<#2494#> #!<#2494#>'', then the first line is parsed and an interpreter is invoked, otherwise the registered binary formats are sequentially tried. The native \ format is supported directly within <#2495#> fs/exec.c<#2495#>, and the relevant functions are <#2496#> load_aout_binary<#2496#> and <#2497#> load_aout_library<#2497#>. As for the binaries, the function loading an <#2498#> a.out<#2498#> executable ends up either in <#2499#> mmap()<#2499#>ing the disk file, or in calling <#2500#> read_exec()<#2500#>. The former way uses the \ demand loading mechanism to fault-in program pages when they're accessed, while the latter way is used when memory mapping is not supported by the host filesystem (for example the ``msdos'' filesystem).

#tex2html_wrap2956#