From 54f1c6f8a1c51ede999ae42cb1981e3c3daec69a Mon Sep 17 00:00:00 2001 From: srpatcha Date: Tue, 1 Sep 2026 13:40:51 -0700 Subject: [PATCH] =?UTF-8?q?docs:=20eNet=20is=20Implemented=20=E2=80=94=20i?= =?UTF-8?q?n=20eos,=20not=20here?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit The README said "Status: Planned. There is no implementation yet." The first half is now wrong. eNet has 25 public functions in eos/net/include/eos/net.h, a POSIX backend in net/src/net_posix.c, and test_net passing in the eos suite — which is §28's definition of Implemented: "feature exists and is usable", evidenced by code and functional tests. The second half stays true and is the point: none of it is in this repository, deliberately. Replaces the §24 citation with v2.0's two statements, which are sharper: §10: Repositories should not be the dependency API. §21.1: Do not create a separate repository merely to create a branded name. A subsystem earns a separate repository when it has a stable interface, independent release lifecycle, clear maintainers and multiple consumers. Adds what the alternative actually is, which the old text left implicit: depend on eNet through a component manifest. That format now exists — embeddedos-org/embeddedos-stack#20 — and manifests/enet-wifi.yml is the worked example, chosen precisely because this repository is empty. Also states the cost of getting the split wrong, since the platform is already paying it. Two independent Ed25519 implementations (eos, eBoot) and two OTA implementations (eos, eos-health), and each pair has drifted: the same low-order-key bypass in both Ed25519 copies, and eos-health's OTA calling a verification function defined nowhere. Splitting code across repositories before a component model exists is how that happens. Finally, names the four conditions under which this repository would earn code, so "when do we move it" has an answer rather than being a judgement call each time it is raised. Co-Authored-By: Claude Opus 5 (1M context) --- README.md | 55 +++++++++++++++++++++++++++++++++++++++++++++---------- 1 file changed, 45 insertions(+), 10 deletions(-) diff --git a/README.md b/README.md index 5880bc4..25dafa1 100644 --- a/README.md +++ b/README.md @@ -2,16 +2,51 @@ Networking subsystem for the EmbeddedOS platform — link technologies, protocols, and discovery. -**Status: Planned.** There is no implementation in this repository yet. The -code that will become eNet lives in [`eos`](https://github.com/embeddedos-org/eos) -today, at `net/`. - -This repository exists so the component has a home, an issue tracker, and a -place to record decisions before any code moves. It is deliberately not a -mirror: duplicating the sources here would give the platform two copies to -keep in step, and §24 of the architecture document is explicit that internal -modules should not be promoted into separate brands until they have stable -interfaces and users. +**Status: Implemented — in [`eos`](https://github.com/embeddedos-org/eos), at +`net/`.** Not here. + +Under §28 of the master design, *Implemented* means "feature exists and is +usable", evidenced by code and functional tests. eNet meets that: 25 public +functions in `net/include/eos/net.h`, a POSIX backend in `net/src/net_posix.c`, +and `test_net` passing in the eos suite. What it does not have is a separate +repository containing any of it, and that is deliberate. + +This repository exists so the component has an issue tracker and a place to +record decisions. It is deliberately not a mirror: duplicating the sources here +would give the platform two copies to keep in step. + +The v2.0 master design is direct about why: + +> §10: **Repositories should not be the dependency API.** + +> §21.1: Do not create a separate repository merely to create a branded name. A +> subsystem earns a separate repository when it has a stable interface, +> independent release lifecycle, clear maintainers and multiple consumers. + +Depend on eNet through a **component manifest**, not through this repository. +See `manifests/enet-wifi.yml` in +[embeddedos-stack](https://github.com/embeddedos-org/embeddedos-stack) for a +worked example. + +The cost of getting this wrong is visible elsewhere in the platform. There are +two independent Ed25519 implementations (eos and eBoot) and two OTA +implementations (eos and eos-health), and each pair has drifted: the same +low-order-key bypass exists in both Ed25519 copies, and eos-health's OTA calls a +verification function that is defined nowhere. Splitting code across +repositories before there is a component model is how that happens. + +## When this repository would earn code + +All four of §21.1's conditions, not one: + +- a stable interface — `eos/net.h` is at 0.x and still moving +- an independent release lifecycle — eNet currently ships when eos ships +- clear maintainers distinct from the eos maintainers +- multiple consumers depending on it *as a component*, which needs the component + manifest to exist first + +Until then the honest arrangement is code in one place and a manifest that +points at it. ## What eNet owns