Re: SVSM Observability and Configuration Protocol draft
Jörg Rödel <[email protected]> Tue, 14 Apr 2026 11:07:14 +0200
| Newsgroups | dev.linux.lists.coconut-svsm |
|---|---|
| Message-ID | <u3espexb4toaxc6w5sz6w72hgbwep2chgj2ej4op2ye3z5lys5@5o6ihdapythk> |
Hi Nicolai, On Tue, Apr 14, 2026 at 10:46:33AM +0200, Nicolai Stange wrote: > > | Offset | Size (Bytes) | Description | > > |-------:|-------------:|-------------------------------------| > > | `0x00` | 4 | Flags | > > | `0x04` | 124 | Name of the source encoded as UTF-8 | > > Just a generic comment: as in my understanding there's no central > authority managing the names, would it perhaps make sense to split the > Name from above into something like a 16 byte UUID + a human readable > name, the latter being only informative (or, alternatively, whose > semantics are defined only within the scope of the UUID)? I am not sure how much value UUIDs add because the read operations work on indexes, but I agree that it makes sense to have a defined set of fixed sources with their indexes as part of the spec. The question is what should be pre-defined besides the log buffer? > > The format of the data allowed to write is source dependent. If a given data > > format is not understood by the source the call will also return > > `SVSM_ERR_INVALID_PARAMETER`. > > I assume other errors would be allowed as well? I'm thinking of a > situation where a "source/configuration" is backed by storage, and > writes to that could fail. True, maybe it makes sense to add some protocol-specific error codes in the 0x8000_0000-0xFFFF_FFFF range. -Joerg