mirror of
https://github.com/logos-blockchain/logos-execution-zone.git
synced 2026-08-26 20:01:16 +00:00
docs(lee,lez): trim PR 740's doc comments, fix stale loader_core crate name
ProgramData::segment_count's doc referenced the pre-rename `loader_core` path; fix to `program_loader_core`. Tighten execute_deploy's and MAX_SEGMENT_DATA_LEN's doc comments and one test's rationale comment.
This commit is contained in:
@@ -65,9 +65,8 @@ pub type ProgramId = [u32; 8];
|
||||
#[derive(Debug, PartialEq, Eq, BorshSerialize, BorshDeserialize)]
|
||||
pub struct ProgramData {
|
||||
pub image_id: ProgramId,
|
||||
/// How many bytecode segment accounts follow, so a reader knows exactly how many
|
||||
/// `loader_core::deploy_segment_account_id(image_id, 0..segment_count, update_auth)`
|
||||
/// accounts to fetch without probing.
|
||||
/// How many bytecode segment accounts follow, so a reader knows how many to fetch without
|
||||
/// probing (see `program_loader_core::deploy_segment_account_id`).
|
||||
pub segment_count: u32,
|
||||
pub update_auth: AccountId,
|
||||
}
|
||||
|
||||
@@ -68,10 +68,8 @@ fn get_program_returns_none_for_a_missing_segment() {
|
||||
assert_eq!(result, None);
|
||||
}
|
||||
|
||||
/// If a segment's bytes are corrupted (or the header's `segment_count` is wrong in a way that
|
||||
/// still finds real segment accounts, just not the right ones), the reconstructed elf's real
|
||||
/// `image_id` won't match what the header claims — `get_program` must reject that distinguishably
|
||||
/// from plain absence, matching "sequencer returns an error about a bad program elf."
|
||||
/// A corrupted segment's reconstructed `image_id` won't match the header's claim —
|
||||
/// `get_program` must reject that distinguishably from plain absence.
|
||||
#[test]
|
||||
fn get_program_rejects_a_corrupted_segment() {
|
||||
let program = crate::test_methods::claimer();
|
||||
|
||||
@@ -22,10 +22,8 @@ const KERNEL_ELF: &[u8] = include_bytes!("kernel.bin");
|
||||
|
||||
/// Max bytes of `user_elf` one segment account's `Data` may hold.
|
||||
///
|
||||
/// Chosen comfortably under `lee_core::account::data::DATA_MAX_LENGTH` (100 KiB), leaving
|
||||
/// headroom for any future per-segment framing without needing to touch this constant, while
|
||||
/// still yielding a sane segment count (4-6) for every real production ELF (340-490 KB
|
||||
/// `user_elf`).
|
||||
/// Comfortably under `DATA_MAX_LENGTH` (100 KiB), with headroom for future per-segment framing;
|
||||
/// yields 4-6 segments for a typical 340-490 KB `user_elf`.
|
||||
pub const MAX_SEGMENT_DATA_LEN: usize = 96 * 1024;
|
||||
|
||||
#[derive(Serialize, Deserialize)]
|
||||
@@ -259,11 +257,9 @@ pub fn immutable_deploy_account_id(image_id: ProgramId) -> AccountId {
|
||||
|
||||
/// Executes the `Deploy` instruction.
|
||||
///
|
||||
/// Verifies `user_elf` decodes as a valid RISC0 program (combined with the assumed
|
||||
/// [`KERNEL_ELF`]), derives its header and segment PDAs (chunking `user_elf` across as many
|
||||
/// segments as [`plan_deploy`] reports), and claims all of them.
|
||||
///
|
||||
/// Called natively from dispatch's `RESERVED_DEPLOYMENT_PROGRAM_ACCOUNT_ID` shortcut (see that
|
||||
/// Verifies `user_elf` decodes as a valid RISC0 program (with the assumed [`KERNEL_ELF`]),
|
||||
/// derives its header and segment PDAs via [`plan_deploy`], and claims all of them. Called
|
||||
/// natively from dispatch's `RESERVED_DEPLOYMENT_PROGRAM_ACCOUNT_ID` shortcut (see that
|
||||
/// constant's doc comment in `lee_core::program`) — `Deploy` has no guest binary of its own.
|
||||
#[must_use]
|
||||
pub fn execute_deploy(
|
||||
|
||||
Reference in New Issue
Block a user