search

microsoft / igvm

MIT License
81 stars 17 forks source link

workspace: disable default features for `hex` #34

Closed stefano-garzarella closed 3 months ago

stefano-garzarella commented 3 months ago

hex by default is built for std. If other no_std crates include igvm as a dependency, during the build Cargo enables features incrementally, thus leaving "std" enabled.

Let's disable hex default features, so if other no_std crates include igvm as a dependency they can be built without errors.

stefano-garzarella commented 3 months ago

@microsoft-github-policy-service agree company="Red Hat, Inc."

chris-oo commented 3 months ago

Thanks for the fix!

Do you have an example of using igvm in no_std? I don't think it works today right, since igvm assumes std? I guess I could rewrite it to only require alloc, but the Error trait still isn't stabilized and would be the blocker...

chris-oo commented 3 months ago

Maybe to clarify - do you have more changes you'd like to submit to get igvm working in a no_std env?

stefano-garzarella commented 3 months ago

I don't have an example, but the problem I had with COCONUT SVSM is that we use igvm for the igvmbuilder which can be used in the std world since it's a tool.

The problem is that we put the igvm dependency in the same workspace of SVSM (no_std), so if we want to use hex in SVSM with the "alloc" feature, we can't since Cargo will build hex for igvm with std enabled.

This one here for me was the quickest fix, but I agree that maybe in SVSM we should have separate workspaces for the tools and for the kernel.

chris-oo commented 3 months ago

I don't think having separate workspaces is necessarily required, as we have some projects that do the same thing and we've had to make similar fixes. I was just curious if no_std igvm was something you were interested in or not.

chris-oo commented 3 months ago

FYI I've just published 0.1.7 to crates.io that has this fix.