Cite the fork, at its revision, in the firmware pages - #103
Merged
Merged
Conversation
docs/firmware-families.md taught anchoring a device log's file:line pairs against upstream release tags. Its own worked example shows what that costs: the log's ocstack.c:537 sits 11 lines past upstream 1.2.1 and 1 line off Samsung's fork at 538. Both readings get the era right and only one gets the tree right. The section now anchors against the vendor tree, describes the drift method over that tree's own history, and says to read the result as an era rather than a commit, since many revisions are identical on every anchor. It also records that some logged strings are in no public revision at all — established with git log -S over the full history, not a look at the tip — and that at least one of them turns up in a capture from a different Samsung product, so that patch layer is shared across device families. The binding table's citations move to fork line numbers, and a new section covers three TizenRT build choices that decide what discovery can reach: IPv6 compiled out rather than unbound, multicast TTL pinned to 1, and a TCP client with no server role. certificates.md gives both trees for the peerId claim, where the code is the same in each. use-of-ai.md's citation rule gains "at the right revision", since a fork of the same stack is what went wrong this time.
The peerId citation pointed at the pin table in AGENTS.md, which arrives with #102 and is not on main yet. test_links_between_markdown_files_ resolve maps a blob/main URL back to a local path, so the link failed the suite on this branch and would have coupled two independent changes in the merge order. The line names the fork and gives both trees' line numbers itself, which is what a reader needs at that point anyway.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Follows #100, which wrote the page this corrects, and #101, which is where the vocabulary comes from.
The anchoring method pointed at the wrong tree.
docs/firmware-families.mdsaid to match a device log'sfile:linepairs against upstream release tags. The page's own worked example is the demonstration: the log'socstack.c:537sits 11 lines past upstream 1.2.1's 526, and 1 line off Samsung's fork at 538. Both readings get the era right; one of them gets the tree right. Anchoring now runs against the vendor tree, with upstream kept for the floor and for showing what Samsung changed.Picking the revision is the same method run over that tree's history, so the page describes it: record the drift for each anchor, expect the appliance's line numbers to sit a little after the tree's, and take the minimum of the summed absolute drift. Two cautions come with it. The answer is an era rather than a commit, because many revisions are identical on every anchor. And some strings in these logs are in no public revision of anything, which
git log -Sover the full history establishes and a look at the tip does not — one of them also appears in a console capture from a different Samsung product, so that patch layer is shared across device families rather than specific to a model.Three TizenRT build choices get their own section, because each decides what discovery can reach and none is visible from upstream source: IPv6 is compiled out rather than merely unbound, multicast TTL is pinned to 1 so discovery cannot leave the segment, and the build is a TCP client with no server role, so
/oic/resadvertises no TCP port to find.The binding table's citations move to fork line numbers, and a sentence spells out what "kernel-assigned" means there: the unicast pair's ports start at 0,
CACreateSocketbinds that, andgetsocknamereads back what the kernel chose.docs/certificates.mdgives both trees for the peerId claim, where the code is the same in each, anddocs/use-of-ai.md's citation rule gains "at the right revision" — a fork of the same stack is what went wrong this time, not a different stack.800 tests pass.
docs/api.mdis unchanged — no docstrings here. Share safety is clean; the one thing it caught was an IPv6 literal for the OCF multicast group, which the text now names instead of spelling.