%
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#