Stefan Berger <stef...@linux.vnet.ibm.com> writes: > On 03/27/2013 12:12 PM, Joel Schopp wrote: >> >>> Yea it's not hard to invent a random format each time we write something >>> on disk. >>> >>> But I think ASN.1 BER will be useful to have in qemu anyway. E.g. it's a >>> better format for migration than what we have now. Once we have it in >>> tree re-using it seems cleaner than maintaining some per-TPM thing. >>> >> >> The asn.1 patches that have been posted seem to be getting a cool >> reception. If people think asn.1 is the way to go some more review >> comments, acked-bys, reviewed-bys, or signed-off-bys would make that >> more likely to happen. The patches have gone through several rounds >> of review and come with a decent set of tests but still haven't been >> merged. I think they are very mergable. > > Let me post another version that makes all the tests in > test-visitor-serialize pass, including the ones using visit_optional.
What I struggle with is that we're calling this a "blobstore". Using BER to store "blobs" seems kind of pointless especially when we're talking about exactly three blobs. I suspect real hardware does something like, flash is N bytes, blob 1 is a max of X bytes, blob 2 is a max of Y bytes, and blob 3 is (N - X - Y) bytes. Do we really need to do anything more than that? Regards, Anthony Liguori > > I also think they are mergeable, but we should discuss a few aspects > around it. There are standards behind this that we may or may not need > to implement as such. I am thinking of CER encoding for example that > imposes restrictions on the size of primitive elements to be less than > 1000 bytes (section 9.2) and need constructed encoding when bigger. We > may be able to change this limit to PAGE_SIZE * n with n = ?. There may > be other aspects. > > Stefan
