phase 19a: scaffold simple-someip-embassy-net workspace member

[JustinKovacich]

New crate at simple-someip-embassy-net/ providing the reference no_std backend for simple-someip's transport-trait surface. As of this commit, the crate is scaffolded only:

• Cargo.toml depends on simple-someip (default-features = false, client+server+bare_metal) and embassy-net = "0.4" (the last release line that builds against embassy-sync 0.6, which is what simple-someip currently uses; bumping both deps in lockstep is its own future phase).
• src/lib.rs declares factory and socket modules plus pub use re-exports for the eventual EmbassyNetFactory / SocketPool / EmbassyNetSocket surface.
• src/factory.rs skeleton declares SocketPool<POOL, RX_BUF, TX_BUF> and EmbassyNetFactory<'a, POOL, RX_BUF, TX_BUF> types with stubbed-out fields (_todo: ()); actual buffer storage and the TransportFactory impl land in 19b.
• src/socket.rs skeleton declares EmbassyNetSocket placeholder; full TransportSocket impl lands in 19c.
• README.md documents target shape (post-19c) and the surrounding bare-metal-plan-v3 phase 19 framing.

Workspace Cargo.toml adds the new member.

Verification:
cargo build -p simple-someip-embassy-net ✓
cargo build -p simple-someip-embassy-net --target thumbv7em-none-eabihf ✓
cargo build --workspace --all-features ✓
cargo clippy --workspace --all-features -- -D warnings -D clippy::pedantic ✓
cargo fmt --all --check ✓

[Copilot]

Pull request overview

Scaffolds a new simple-someip-embassy-net crate intended to provide a no_std embassy-net backend implementing simple-someip’s transport trait surface, and wires it into the workspace.

Changes:

• Add new workspace member crate simple-someip-embassy-net with initial module/type skeletons.
• Add crate documentation (crate-level docs + README) describing the intended phase-based implementation plan.
• Update workspace membership and lockfile to include new dependencies.

Reviewed changes

Copilot reviewed 6 out of 7 changed files in this pull request and generated 7 comments.

Show a summary per file

File	Description
Cargo.toml	Adds simple-someip-embassy-net as a workspace member.
Cargo.lock	Adds new dependency resolutions for the new crate and embassy ecosystem deps.
simple-someip-embassy-net/Cargo.toml	Defines the new crate’s package metadata and dependency set (including embassy-net = 0.4).
simple-someip-embassy-net/README.md	Documents the intended “post-19c” public shape and roadmap context.
simple-someip-embassy-net/src/lib.rs	Establishes no_std crate root, modules, and re-exports for the planned API surface.
simple-someip-embassy-net/src/factory.rs	Adds skeleton SocketPool / EmbassyNetFactory types for phase 19a.
simple-someip-embassy-net/src/socket.rs	Adds placeholder EmbassyNetSocket type for phase 19a.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

The quick-sketch calls EmbassyNetFactory::new(stack, &SOCKET_POOL), but the current scaffolded API is EmbassyNetFactory::new(pool) (and EmbassyNetFactory doesn't store a Stack yet). Even if this is meant to describe the post-19c shape, it’s currently inconsistent with the crate’s public constructor and will confuse early adopters; please update the snippet to match the intended signature (or explicitly annotate the snippet with the planned new(stack, pool) signature and timeline).

Suggested change

	let stack = /* ... build embassy-net Stack ... */;
	let factory = EmbassyNetFactory::new(stack, &SOCKET_POOL);
	let _stack = /* ... build embassy-net Stack ... */;
	// Current scaffolded API takes only the pool; stack integration is part of the planned post-19c shape.
	let factory = EmbassyNetFactory::new(&SOCKET_POOL);

[Copilot]

plan-v3 is referenced as the bare-metal roadmap, but the link currently points to the repository root rather than the specific plan document (and bare_metal_plan_v3.md does not appear to exist in-tree). Please update this link to the actual plan location (e.g., a /blob/.../bare_metal_plan_v3.md URL) or adjust the text to reference an existing document.

[Copilot]

This comment says embassy-net 0.4.x “builds against embassy-sync 0.6”, but the resolved dependency graph shows embassy-net 0.4.0 depends on embassy-sync 0.5.0 (see Cargo.lock). Please correct the rationale (e.g., that 0.4 avoids pulling embassy-sync 0.7+, not that it uses 0.6), since this is important for understanding the version-pinning and binary-size tradeoffs.

Suggested change

	# Pinned to a version known to coexist with `simple-someip`'s
	# `embassy-sync = "0.6"` dep. embassy-net 0.4.x is the last
	# release line that builds against embassy-sync 0.6; later
	# embassy-net releases (0.5+) require embassy-sync 0.7+, which
	# would force a parallel-version cargo resolution that bloats the
	# binary. Bumping both deps in lockstep is its own future phase.
	# Pinned to a version known to coexist with this crate's
	# `embassy-sync = "0.6"` dep. embassy-net 0.4.x avoids the newer
	# embassy-net release lines (0.5+) that require embassy-sync 0.7+,
	# which would force a parallel-version cargo resolution alongside
	# our direct `embassy-sync = "0.6"` and bloat the binary. Bumping
	# both deps in lockstep is its own future phase.

[Copilot]

This crate references bare_metal_plan_v3.md, but that file doesn’t appear to be present in the repository root. Please either add the referenced doc, or update the reference to the correct in-tree filename/location to avoid dead documentation pointers.

Suggested change

	# See `bare_metal_plan_v3.md` for the surrounding plan (phase 19).
	# This crate corresponds to the bare-metal backend plan work
	# (phase 19).

[Copilot]

The docs reference bare_metal_plan_v3.md, but that file doesn’t appear to exist in-tree. Please update the reference to the correct document/location (or add the missing file) so the crate-level docs don’t point to a dead path.

Suggested change

	//! Phase 19 in progress (per `bare_metal_plan_v3.md`). 19a (this
	//! commit) is the scaffold; 19b implements [`EmbassyNetFactory`],
	//! 19c implements [`EmbassyNetSocket`], 19e wires up the loopback
	//! integration test, 19f produces an in-tree example.
	//! Phase 19 is in progress. 19a (this commit) is the scaffold; 19b
	//! implements [`EmbassyNetFactory`], 19c implements
	//! [`EmbassyNetSocket`], 19e wires up the loopback integration
	//! test, 19f produces an in-tree example.

[Copilot]

The doc comment says EmbassyNetFactory “holds a reference to the embassy-net Stack and a &'static SocketPool”, but the scaffolded struct currently only stores pool: &'a SocketPool<...> (no stack field, and not necessarily 'static). Please adjust the docs to match the current type (or add an explicit placeholder field/PhantomData and note it’s added in 19b) to avoid misleading API documentation.

Suggested change

	/// Holds a reference to the embassy-net `Stack` and a `&'static`
	/// [`SocketPool`] from which `bind()` allocates per-socket buffers.
	///
	/// **NB phase 19a:** the [`TransportFactory`](simple_someip::transport::TransportFactory)
	/// trait impl lands in 19b. This skeleton exists so downstream code
	/// In this phase-19a skeleton, the factory currently stores only a
	/// borrowed [`SocketPool`] with lifetime `'a`, from which `bind()`
	/// will eventually allocate per-socket buffers.
	///
	/// The embassy-net `Stack` reference and full
	/// [`TransportFactory`](simple_someip::transport::TransportFactory)
	/// impl are deferred to 19b. This skeleton exists so downstream code

[Copilot]

This doc comment refers to holding an embassy_net::udp::UdpSocket<'a>, but EmbassyNetSocket currently has no lifetime parameter. If the intent is to store UdpSocket<'static> (since buffers come from &'static storage), please update the docs accordingly; otherwise consider adding the lifetime parameter in the type definition even in the scaffold to keep the docs/type shape aligned.

Suggested change

	/// Holds an `embassy_net::udp::UdpSocket<'a>` borrowing into
	/// caller-owned `&'static` buffer storage (managed by
	/// Holds an `embassy_net::udp::UdpSocket<'static>` backed by
	/// caller-provided `&'static` buffer storage (managed by