loader protocol: remove entrypoint
This commit is contained in:
parent
d4b8229981
commit
99f320fdea
@ -0,0 +1,111 @@
|
|||||||
|
# Agenda - Cartridge Manifest Entrypoint Removal and Runtime Protocol
|
||||||
|
|
||||||
|
## Problema
|
||||||
|
|
||||||
|
O runtime ainda trata `entrypoint` como dado vindo do `manifest.json`.
|
||||||
|
|
||||||
|
Hoje isso aparece em mais de uma camada:
|
||||||
|
|
||||||
|
- o `manifest.json` carrega `entrypoint`;
|
||||||
|
- o loader desserializa e propaga esse campo;
|
||||||
|
- o `Cartridge` e o `CartridgeDTO` preservam esse valor;
|
||||||
|
- o runtime system passa esse valor para a VM;
|
||||||
|
- e a VM ainda resolve boot usando string nominal, índice numérico ou fallback vazio.
|
||||||
|
|
||||||
|
Ao mesmo tempo, a linha nova do compiler/PBS está convergindo para outro modelo:
|
||||||
|
|
||||||
|
- o compiler publica um wrapper sintético como entrypoint físico;
|
||||||
|
- esse wrapper deve ocupar o índice físico `0`;
|
||||||
|
- e o entrypoint deixa de ser uma escolha configurável no manifesto para virar protocolo fixo do artefato.
|
||||||
|
|
||||||
|
Isso cria uma divergência concreta entre contrato atual do runtime e direção desejada do compiler.
|
||||||
|
|
||||||
|
## Dor
|
||||||
|
|
||||||
|
- O runtime mantém autoridade duplicada com o compiler sobre qual callable inicia o programa.
|
||||||
|
- O loader continua aceitando modelo nominal de entrypoint que o compiler quer abandonar.
|
||||||
|
- O `manifest.json` carrega responsabilidade que deveria pertencer ao protocolo executável.
|
||||||
|
- O caminho atual mistura:
|
||||||
|
- resolução nominal por export,
|
||||||
|
- resolução por índice,
|
||||||
|
- e fallback implícito.
|
||||||
|
- Essa flexibilidade aumenta superfície de erro e enfraquece determinismo do boot.
|
||||||
|
|
||||||
|
## Alvo da Discussao
|
||||||
|
|
||||||
|
Definir a remoção de `entrypoint` do `manifest.json` e a migração do runtime para um protocolo fixo em que o entrypoint executável do cartucho é sempre o índice `0`.
|
||||||
|
|
||||||
|
O objetivo não é apenas "apagar um campo JSON".
|
||||||
|
|
||||||
|
Precisamos fechar:
|
||||||
|
|
||||||
|
- novo contrato do loader;
|
||||||
|
- impacto em `CartridgeManifest`, `CartridgeDTO` e `Cartridge`;
|
||||||
|
- impacto em `VirtualMachine::initialize(...)`;
|
||||||
|
- impacto em `VirtualMachineRuntime`;
|
||||||
|
- política de compatibilidade transitória;
|
||||||
|
- e a superfície de erro quando o artefato não cumprir o protocolo esperado.
|
||||||
|
|
||||||
|
## O Que Precisa Ser Definido
|
||||||
|
|
||||||
|
1. Contrato final do manifest.
|
||||||
|
O campo `entrypoint` deixa de existir por completo?
|
||||||
|
|
||||||
|
2. Contrato final do loader.
|
||||||
|
O loader deve parar de propagar qualquer entrypoint textual e assumir sempre boot pelo índice `0`?
|
||||||
|
|
||||||
|
3. Contrato final da VM.
|
||||||
|
`VirtualMachine::initialize(...)` continua recebendo `entrypoint: &str`, ou a API deve ser endurecida para boot protocolar sem parâmetro textual?
|
||||||
|
|
||||||
|
4. Compatibilidade transitória.
|
||||||
|
O runtime aceita manifestos antigos com `entrypoint` por um período, ignora com warning, ou rejeita explicitamente?
|
||||||
|
|
||||||
|
5. Superfície de erro.
|
||||||
|
Qual erro canônico deve aparecer quando o artefato não tiver função válida no índice `0`?
|
||||||
|
|
||||||
|
6. Relação com exports nominais.
|
||||||
|
Exports continuam existindo para linking/introspection, mas deixam de participar da autoridade de boot?
|
||||||
|
|
||||||
|
## Contexto Atual Observado
|
||||||
|
|
||||||
|
Hoje o acoplamento aparece ao menos nestes pontos do runtime:
|
||||||
|
|
||||||
|
- `prometeu-hal`:
|
||||||
|
- `CartridgeManifest.entrypoint`
|
||||||
|
- `CartridgeDTO.entrypoint`
|
||||||
|
- `Cartridge.entrypoint`
|
||||||
|
- `cartridge_loader`:
|
||||||
|
- leitura e propagação de `manifest.entrypoint`
|
||||||
|
- `prometeu-system`:
|
||||||
|
- `initialize_vm()` repassa `cartridge.entrypoint`
|
||||||
|
- `current_entrypoint` ainda é rastreado
|
||||||
|
- `prometeu-vm`:
|
||||||
|
- `initialize(program_bytes, entrypoint)`
|
||||||
|
- resolução por string, índice ou fallback
|
||||||
|
|
||||||
|
Isso mostra que a mudança necessária é funcional e estrutural, não apenas uma validação de manifesto.
|
||||||
|
|
||||||
|
## O Que Necessita Para Resolver
|
||||||
|
|
||||||
|
- decisão clara sobre estado final do protocolo;
|
||||||
|
- decisão clara sobre compatibilidade transitória;
|
||||||
|
- inventário de tipos/APIs a alterar no runtime;
|
||||||
|
- atualização de testes de loader, system runtime e VM init;
|
||||||
|
- alinhamento com spec do cartridge manifest e com a política de `func_id = 0`.
|
||||||
|
|
||||||
|
## Fora de Escopo
|
||||||
|
|
||||||
|
- discutir novamente qual callable do usuário é o root lógico;
|
||||||
|
- discutir wrapper sintético do compiler em detalhe;
|
||||||
|
- discutir lowering FE/BE do compiler;
|
||||||
|
- redesign geral do formato `manifest.json` além do campo `entrypoint`.
|
||||||
|
|
||||||
|
## Critério de Saida Desta Agenda
|
||||||
|
|
||||||
|
Pode virar decision quando houver definição escrita de:
|
||||||
|
|
||||||
|
- remoção ou não de `entrypoint` do manifest como contrato final;
|
||||||
|
- política de transição para cartuchos antigos;
|
||||||
|
- novo contrato do loader/VM para boot em índice `0`;
|
||||||
|
- erros canônicos quando o protocolo não for satisfeito;
|
||||||
|
- e escopo mínimo de mudanças de código e testes no runtime.
|
||||||
Loading…
x
Reference in New Issue
Block a user