diff options
| author | Florian Klink <flokli@flokli.de> | 2024-08-13T16·27+0300 |
|---|---|---|
| committer | clbot <clbot@tvl.fyi> | 2024-08-13T18·52+0000 |
| commit | 97c60d9857432a76009bf3e10a75a467ee9ddf7b (patch) | |
| tree | e16ac6cc2b981f94c731a54e25569c63891fa5e1 | |
| parent | c7845f3c882d0f1b215813bf0ef8231c2c03d7b6 (diff) | |
docs(tvix/TODO): castore Directory struct is done r/8487
There's some followup work on making tvix-build use the stricter structs natively, but that should probably be combined with the overall trait changes there. Add an item there so we won't forget, but this isn't really castore territory anymore. Change-Id: I6b1f9fa02d5c87c821d4ddc4b1dcc6a98c4eeaa5 Reviewed-on: https://cl.tvl.fyi/c/depot/+/12200 Autosubmit: flokli <flokli@flokli.de> Tested-by: BuildkiteCI Reviewed-by: yuka <yuka@yuka.dev> Reviewed-by: Ilan Joselevich <personal@ilanjoselevich.com>
| -rw-r--r-- | tvix/docs/src/TODO.md | 24 |
1 files changed, 8 insertions, 16 deletions
diff --git a/tvix/docs/src/TODO.md b/tvix/docs/src/TODO.md index 3efcb0606f71..af558c9580fe 100644 --- a/tvix/docs/src/TODO.md +++ b/tvix/docs/src/TODO.md @@ -25,20 +25,6 @@ sure noone is working on this, or has some specific design in mind already. with a different level of `--strict`, but the toplevel doc-comment suggests its generic? -### castore - - The `Directory` struct is currently being generated from the protobuf definitions. - We should change this, have `Directory` be our own type (holding a `B3Digest`), - rather than a `Vec<u8>`, and move impls to there. - The protobuf struct can stay in `castore/proto`, but should only be used - when converting to/from Protobuf definitons: - - gRPC client/server impls - - implementations that use protobuf as a internal data format - - `digest()` implementation of our stricter `Directory` struct - - The traits should use our stricter type. This would allow removing a lot of - the checks we currently have when converting from `Vec<u8>` to `B3Digest` in - various places. - ### Correctness > Performance A lot of the Nix behaviour isn't well documented out, and before going too deep into performance optimizations, we need to ensure we properly grasped all hidden @@ -158,8 +144,14 @@ there are ruled out, adding other types of builders might be interesting. - gVisor - Cloud Hypervisor (using similar technique as `//tvix//boot`). -Long-term, we want to extend traits and gRPC protocol to expose more telemetry, -logs etc, but this is something requiring a lot of designing. +Long-term, we want to extend traits and gRPC protocol. +This requires some more designing. Some goals: + + - use stricter castore types (and maybe stricter build types) instead of + proto types, add conversion code where necessary + - (more granular) control while a build is happening + - expose more telemetry and logs + ### Store composition - Combinators: list-by-priority, first-come-first-serve, cache |