Allow precise host-function requirements for snapshot/restore
Maintainer antworten meist innerhalb von 7 Tagen
Dieses Issue hat noch niemand übernommen.
Bewertung
- Schwierigkeit
- 4/5
- Geschätzter Aufwand
- 3-5 Tage
- Anfängerfreundlichkeit
- 52/100
- Issue-Typ
- Feature
- Klarheit
- Größtenteils klar
- Aktivitätsstatus
- Aktiv
- Tech-Stack
- javascript, rust
- Bereich
- backend
Rechercherichtung
Start by locating the handler and module registration APIs, then trace how snapshot and restore state tracks available and required host functions. Define the optional per-item requirement declarations and verify that omitted declarations retain conservative promotion while removals recompute the union of declared requirements.
Vom Indexierungsmodell aus dem Issue-Text verfasst.
Beschreibung
Problem
Hyperlight-JS snapshots distinguish:
available: callbacks installed in the destination hostrequired: callbacks exposed to the current guest state and recorded in snapshots
Consider:
- Snapshot requires function A.
- Destination provides A and B.
- Restore preserves
required = {A}andavailable = {A, B}. - A new handler that calls B is staged.
- The next snapshot must require both A and B.
Hyperlight-JS cannot reliably infer host-function dependencies from arbitrary
JavaScript. Imports and property access can be dynamic, and runtime observation
would miss unexecuted branches.
The current safe behavior conservatively promotes required to the complete
available manifest whenever a handler or module is added after restoration.
This is correct but can overstate requirements and reduce snapshot portability.
Proposed solution
Add an optional API for declaring host-function requirements when registering
handlers and modules. Track requirements per registered item so removals can
recompute the resulting union.
Callers that omit declarations retain the conservative promotion behavior.
- Vorherrschende Sprache
- Rust
- Sterne
- 16
- Forks
- 5
- Ø Merge
- 7 T. 3 Std.
- Gemergte PRs (30 T.)
- 28
Entwicklungsumgebung
Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.
- Kein Dockerfile und keine Docker-Compose-Datei
- Keine Pull-Request-Vorlage
- Beitragsleitfaden lesen
Erste Schritte
- Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
- Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
- Forken Sie das Repository und arbeiten Sie in einem Branch.
- Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.
Mehr aus hyperlight-dev/hyperlight-js
-
lifecycle/needs-review
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 68/100
hyperlight-dev/hyperlight-js#81 ·
Maintainer antworten meist innerhalb von 7 Tagen
-
lifecycle/needs-review
Schwierigkeit 4/5 3-5 Tage Anfängerfreundlichkeit 48/100
hyperlight-dev/hyperlight-js#340 ·
Maintainer antworten meist innerhalb von 7 Tagen
-
lifecycle/needs-review
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 35/100
hyperlight-dev/hyperlight-js#339 ·
Maintainer antworten meist innerhalb von 7 Tagen
-
lifecycle/needs-review
Schwierigkeit 3/5 1-2 Tage Anfängerfreundlichkeit 55/100
hyperlight-dev/hyperlight-js#337 ·
Maintainer antworten meist innerhalb von 7 Tagen
-
lifecycle/needs-review
Schwierigkeit 5/5 Über eine Woche Anfängerfreundlichkeit 35/100
hyperlight-dev/hyperlight-js#312 ·
Maintainer antworten meist innerhalb von 7 Tagen
Alle Issues in hyperlight-dev/hyperlight-js
Ähnliche Issues
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 77/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 72/100
Maintainer antworten meist innerhalb von 1 Tag
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 65/100
chrisdickinson/trivia#26 ·
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 62/100
-
Schwierigkeit 2/5 1-3 Stunden Anfängerfreundlichkeit 66/100