Skip to content
This repository was archived by the owner on Oct 25, 2025. It is now read-only.

chore: Move some sdk::core types to their own crate, sdk-core-types#1693

Closed
codeblooded1729 wants to merge 12 commits intomainfrom
kapil/sdk_core_types
Closed

chore: Move some sdk::core types to their own crate, sdk-core-types#1693
codeblooded1729 wants to merge 12 commits intomainfrom
kapil/sdk_core_types

Conversation

@codeblooded1729
Copy link
Contributor

Main benefit is that circuits and runner no longer have sdk as dependency.

@codeblooded1729 codeblooded1729 changed the title chore: Move some sdk::core types to its own crate chore: Move some sdk::core types to their own crate, sdk-core-types May 10, 2024
edition = "2021"
keywords = ["sdk", "types"]
license = "Apache-2.0"
name = "sdk-core-types"
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
name = "sdk-core-types"
name = "core"

I'd argue you could even just name this core. ecall IDs and poseidon2 constants aren't really types, and they aren't really constrained to SDK usage only.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

core sounds like functionality. These are not such elements if I understand correctly.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You are right. Creating a separate crate for extracting out constants doesn't seem like the best thing to do.

@@ -2,45 +2,16 @@
use core::arch::asm;

#[cfg(target_os = "mozakvm")]
Copy link
Contributor

@spiral-ladder spiral-ladder May 13, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

One of the benefits of moving the consts and the log fn out of this file is that we can now put this cfg file-wide at the top of the file:

#![cfg(target_os = "mozakvm")]

And remove all the per fn/import configuration.

use sdk_core_types::ecall_id;

#[must_use]
pub fn log<'a>(raw_id: u32) -> &'a str {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

IMO, please either:

  1. provide a doc comment on what this is meant to log,
  2. or just put this fn within ecall(), since that's the only place this is used. Then there would be no ambiguity in what this fn is meant to log.

Comment on lines +3 to +4
use mozak_runner::reg_abi::REG_A1;
use sdk_core_types::constants::poseidon2::DIGEST_BYTES;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Doesn't this look weird?

args: Args {
rd: REG_A0,
imm: ecall::POSEIDON2,
imm: ecall_id::POSEIDON2,
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We moved from ecall_id -> ecall -> ecall_id again

mozak-sdk = { path = "../sdk" }
plonky2 = { workspace = true, default-features = false }
proptest = { version = "1.4", optional = true }
sdk-core-types = { path = "../sdk-core-types" }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why not just types?

@@ -0,0 +1,4 @@
#![cfg_attr(target_os = "mozakvm", no_std)]

pub mod constants;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pub mod poseidon2hash maybe.

@codeblooded1729
Copy link
Contributor Author

The goal of this PR was to break the dependency of circuits and runner over sdk, so that we can add these as dependencies for sdk itself. Turned out there isn't much to gain from this PR other than migrating constants to a separate crate. I came up with hopefully better solution, by introducing a variant of sdk which has the abovementioned dependencies. Closing this in favor of that PR #1701

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants