No sched_init ( ) o 1 dt e tss descritores para tarefa [0] são postos no GDT, e carregado para dentro do TR e LDTR (a única vez que isto é feito explicitamente). Um trap gate (0X80) é ordenado para system-call.( ).
A bandeira tarefa aninhada é desligada na preparação para entrada do modo usuário: O cronômetro é ligado. O task-struct para task [0] aparece por inteiro em < linux / sched.h > mem_map é então construído por mem_init ( ) para refletir o corrente uso das páginas físicas. Este é o estado refletido no mapa da memória física da seção anterior.
Então Dinux move para dentro do modo usuário com um iret após empurrar o corrente ss, esp, etc. Claro que o segmento usuário para task [0] são mapeados bem sobre os segmentos Kernel e deste modo a execução continua exatamente onde isto termina.
Task [0]:
pg_dir = swapper – pg – dir que sigmifica apenas endereços mapeados estão no alcance 3 Gb para 3 Gb + High memory.
LTD [1] = código usuário, base = 0 x 0000000, tamanho = 640 K
LDT [2] = dados usuários, base = 0 x 0000000, tamanho = 640 k
O primeiro exec ( ) põe a LTD entrada para task [1] para os valores usuários da base = 0x0, limite = task_size = 0 x c 0000000. Depois disso, nenhum processo vê os segmentos Kernel enquanto no modo usuário.
Processos e a Administração da Memória.
Memória relacionada trabalho feito por fork ( ):
• distribuição de memória
• 1 página para o Task-struct
• 1 página para o Kernel Stack
• 1 para o pg_dir e algumas para pg_tables (cópias – páginas – tabelas)
• Outras mudanças
• sso põe para o segmento Kernel stack (0x10) para ter certeza?
• espo põe para o topo da nova distribuição Kernel – stack – page.
• c r 3 põe por copy – page – tables ( ) para indicar para nova página de
diretório distribuída
• 1 dt = LDT (task_nr) cria novo 1 dt descritor
• descritores põe no gdt para novo tss e 1 dt [ ]
• Os registros restantes são herdados do parent.
Os processos resultam dividindo seus códigos e segmentos de dados (embora eles tenham tabelas descritoras locais separados, as entradas indicam para os mesmos segmentos).
O stack e páginas de dados serão copiados quando o parent ou child escreve para eles ( copy-on-write).
Memória relacionada trabalho feito por exec ( ):
• distribuição de memória
• 1 página para exec header para omagic
• 1 página ou mais para stack (max_arg_pages)
• clear-página-tables ( ) usado para remover páginas velhas.
• change 1 dt ( ) põe os descritores no novo 1 dt [ ]
• 1 dt [1] = código base = 0 x 00, limite = task – size
• 1 dt [2] = data base = 0 x 00, limite = task – size Estes segmentos são dpl = 3, p=1, s=1, g=1.
Tipo = a (código or 2 dados)
• Eleva para MAX_ARG_PAGES páginas sujas de arqu e enup são distribuídos e guardado ao topo do segmento de
dados para o novo usuário pilha criado.
• Ponha os indicadores de instrução do caller cip = ex.a_cutry
• Ponha o stack indicador do caller para o stack criado (esp=stack indicador). Este serão eliminados do Stack quando o
caller resume.
Limites de Memória Atualizados
• cud_code = ex.a_text
• cud_data = cud_code + &x.d_data
• brK = end_data + ex.ª_bss