操作系統(tǒng)嵌入式嵌入式OS【免費(fèi)下載鏈接】tockA secure embedded operating system for microcontrollers項(xiàng)目地址https://gitcode.com/gh_mirrors/to/tock點(diǎn)擊查看免費(fèi)下載導(dǎo)讀本文基于 doc/Maintenance.md 梳理 Tock面向微控制器的安全嵌入式操作系統(tǒng)核心工作組Core Working Group的項(xiàng)目維護(hù)機(jī)制涵蓋長(zhǎng)期路線(xiàn)圖規(guī)劃、社區(qū)教育與推廣、里程碑驅(qū)動(dòng)的發(fā)布策略含分支、標(biāo)簽與版本號(hào)管理細(xì)則以及系統(tǒng)調(diào)用驅(qū)動(dòng)Syscall Driver的穩(wěn)定化流程。讀完本文你將能夠理解 Tock 從「規(guī)劃—開(kāi)發(fā)—測(cè)試—發(fā)布—下一個(gè)版本迭代」的完整閉環(huán)掌握release-blocker標(biāo)簽、release/$major.$minor分支、annotated tag 與KERNEL_*_VERSION常量的具體用法并了解如何推動(dòng)一個(gè)系統(tǒng)調(diào)用驅(qū)動(dòng)走向「穩(wěn)定」?fàn)顟B(tài)。一、誰(shuí)來(lái)維護(hù) Tock核心工作組的角色Tock 的維護(hù)工作主要由 核心工作組core working group 負(fù)責(zé)。根據(jù)其章程Adopted 3/31/2020Amended 3/01/2024核心工作組的職責(zé)包括管理并監(jiān)督 Tock 的代碼、文檔、測(cè)試與發(fā)布定義并傳達(dá)項(xiàng)目總體目標(biāo)與方向?qū)⒔M件與子項(xiàng)目的責(zé)任下放給各工作小組并確保其擁有完成任務(wù)所需的人力和資源協(xié)調(diào)跨多個(gè)工作小組的決策包括代碼、文檔、測(cè)試和發(fā)布促進(jìn)各工作小組之間的溝通與共識(shí)。核心工作組成員是 Tock 倉(cāng)庫(kù)中擁有提交PR 合并權(quán)限的人中的一部分代表項(xiàng)目的主要視角與核心議題。成員加入需由現(xiàn)有成員提名并通過(guò)修改 doc/wg/core/README.md 的 Pull Request 完成。工作組每周召開(kāi)電話(huà)會(huì)議并在會(huì)議后一周內(nèi)發(fā)布詳細(xì)的會(huì)議記錄作為對(duì)外溝通渠道。路線(xiàn)圖與特性規(guī)劃Roadmap and Feature PlanningTock 的重大長(zhǎng)期規(guī)劃主要在周期性舉辦的Tock World研討會(huì)上完成——核心工作組成員和其他利益相關(guān)者齊聚一堂討論 Tock 新特性的設(shè)計(jì)與項(xiàng)目總體目標(biāo)頻率大約為每年一次。除此之外日常的規(guī)劃工作則發(fā)生在每周的核心工作組電話(huà)會(huì)議上。推廣與教育Outreach and Education作為一個(gè)開(kāi)源項(xiàng)目Tock 核心工作組還會(huì)定期在學(xué)術(shù)與專(zhuān)業(yè)會(huì)議期間舉辦交互式教程tutorials為感興趣的開(kāi)發(fā)者提供親手使用 Tock 的實(shí)戰(zhàn)機(jī)會(huì)。此外項(xiàng)目還維護(hù)了一本包含多種 Tock 特性自助教程的在線(xiàn)書(shū)籍book.tockos.org作為持續(xù)性的學(xué)習(xí)資料。二、Tock 發(fā)布策略里程碑驅(qū)動(dòng)而非時(shí)間驅(qū)動(dòng)Tock 的發(fā)布采用**里程碑驅(qū)動(dòng)milestone-based**策略大致預(yù)期每3–12 個(gè)月發(fā)布一個(gè)新版本。其核心流程是在發(fā)布之前將一批 issue 打上release-blocker標(biāo)簽當(dāng)計(jì)劃納入本次發(fā)布的所有release-blockerissue 全部關(guān)閉后創(chuàng)建新的發(fā)布分支在發(fā)布分支上進(jìn)行測(cè)試與驗(yàn)證分支穩(wěn)定后打上發(fā)布標(biāo)簽tag發(fā)布后分支不刪除后續(xù)修復(fù)繼續(xù)合入該分支用于打補(bǔ)丁版本patch release。關(guān)于release-blocker有一個(gè)重要的細(xì)節(jié)針對(duì)下一個(gè)主版本major version的 release blocker 不必阻塞小版本minor version的發(fā)布。也就是說(shuō)release-blocker的生效范圍是按發(fā)布版本類(lèi)別區(qū)分的。歷史背景Tock 早期曾采用時(shí)間驅(qū)動(dòng)的發(fā)布策略目標(biāo)每?jī)蓚€(gè)月發(fā)布一次初衷是讓用戶(hù)更容易安裝和追蹤 Tock 的變化。但維持這一節(jié)奏的維護(hù)開(kāi)銷(xiāo)過(guò)大且經(jīng)常與發(fā)布節(jié)點(diǎn)上正在開(kāi)發(fā)中的重大特性沖突因此后來(lái)轉(zhuǎn)向了里程碑驅(qū)動(dòng)策略。發(fā)布分支Release Branches一旦所有 release-blocker issue 關(guān)閉即創(chuàng)建新的發(fā)布分支命名格式為release/$major.$minor例如release/1.4。該分支專(zhuān)用于即將發(fā)布版本的測(cè)試與驗(yàn)證。分支在發(fā)布后不會(huì)被刪除后續(xù)修復(fù)會(huì)持續(xù)合并進(jìn)該分支并用于標(biāo)記新的補(bǔ)丁版本。發(fā)布標(biāo)簽Release Tags發(fā)布測(cè)試通過(guò)后打上發(fā)布標(biāo)簽。Tock 要求發(fā)布標(biāo)簽必須是annotated tag帶注釋的標(biāo)簽而不是 GitHub Release 默認(rèn)創(chuàng)建的 lightweight taggit tag -a release-$major.$minor.$patch -m Release notes...標(biāo)簽名稱(chēng)格式為release-$major.$minor.$patch某個(gè) minor 版本的首個(gè)發(fā)布patch 號(hào)取0標(biāo)簽應(yīng)包含與對(duì)應(yīng) GitHub Release 相同的發(fā)布說(shuō)明release notes使用git tag -a創(chuàng)建的 annotated tag 會(huì)被 Git 視為發(fā)布質(zhì)量標(biāo)簽例如git describe可以識(shí)別。三、發(fā)布任務(wù)全流程Release Tasks3.1 發(fā)布前Before the release發(fā)布前的準(zhǔn)備工作包括決定本次發(fā)布應(yīng)納入哪些特性在相關(guān) issue 和 Pull Request 上標(biāo)記release-blocker標(biāo)簽開(kāi)啟一個(gè)標(biāo)題為Release 的追蹤 issue其中包含本次發(fā)布的目標(biāo)列表用于測(cè)試每塊開(kāi)發(fā)板board的模板清單checklist供每位核心工作組成員簽核sign-off的清單持續(xù)處理帶有release-blocker標(biāo)簽的 issue 和 PR直至全部關(guān)閉。3.2 發(fā)布測(cè)試Release testing發(fā)布測(cè)試由核心工作組成員和各開(kāi)發(fā)板維護(hù)者共同執(zhí)行。測(cè)試在分支出來(lái)的發(fā)布分支上進(jìn)行而不是在master上。測(cè)試的具體操作流程如下選擇一塊要測(cè)試的開(kāi)發(fā)板從上一次發(fā)布的追蹤 issue 中復(fù)制該開(kāi)發(fā)板的測(cè)試清單并取消所有勾選將復(fù)制的清單發(fā)布到新版本的追蹤 issue 中——這表示你認(rèn)領(lǐng)了該開(kāi)發(fā)板的測(cè)試工作增加本次發(fā)布你希望額外運(yùn)行的測(cè)試。例如如果該開(kāi)發(fā)板自上次發(fā)布以來(lái)新增了 capsule可相應(yīng)地為新 capsule 添加測(cè)試運(yùn)行測(cè)試每完成一項(xiàng)即在清單中勾選。若測(cè)試失敗編輯你在 issue 中的評(píng)論將該測(cè)試項(xiàng)標(biāo)記為X表示失敗并附上失敗原因的說(shuō)明對(duì)所有失敗的測(cè)試要么提交修復(fù) PR要么開(kāi)啟描述該失敗的 issue 尋求幫助。Tock 刻意不在倉(cāng)庫(kù)中維護(hù)固定的測(cè)試列表而是采用「上一輪該板卡運(yùn)行過(guò)的全部測(cè)試 維護(hù)者本輪新增的測(cè)試」的方式讓測(cè)試覆蓋隨板卡功能演進(jìn)自然增長(zhǎng)。如果在測(cè)試過(guò)程中發(fā)現(xiàn) bug 且需要大量修改可以再打**發(fā)布候選release candidate**標(biāo)簽。是否需要對(duì)所有板卡重新測(cè)試由核心工作組決定。3.3 打發(fā)布標(biāo)簽Tagging a release當(dāng)以下條件全部滿(mǎn)足時(shí)即可打發(fā)布標(biāo)簽所有板卡的測(cè)試全部通過(guò)更新了 CHANGELOG.md該文件按版本記錄每個(gè)發(fā)布的新特性、修復(fù)與兼容性說(shuō)明例如「New in 2.2」章節(jié)記錄了約 3900 個(gè) commit、840 個(gè) PR 以及向后兼容性承諾將 kernel/src/lib.rs 中的KERNEL_PRERELEASE_VERSION設(shè)置為0表示這是正式發(fā)布版本更新根目錄 Cargo.toml 中的版本號(hào)。3.4 啟動(dòng)下一個(gè)版本Starting the next release在分支發(fā)布之后立即開(kāi)始下一輪迭代操作如下在master分支上遞增 minor 版本號(hào)并將 patch 版本號(hào)清零在根目錄 Cargo.toml 中把版本設(shè)置為新版本-dev例如當(dāng)前倉(cāng)庫(kù)中的version 0.2.4-dev在 kernel/src/lib.rs 中更新KERNEL_MAJOR_VERSION、KERNEL_MINOR_VERSION、KERNEL_PATCH_VERSION并將KERNEL_PRERELEASE_VERSION設(shè)為1。版本號(hào)在源碼中的落地Kernel Attributes版本信息不僅僅是文檔約定它被真實(shí)編譯進(jìn)內(nèi)核二進(jìn)制。在 kernel/src/lib.rs 中KERNEL_MAJOR_VERSION、KERNEL_MINOR_VERSION、KERNEL_PATCH_VERSION、KERNEL_PRERELEASE_VERSION四個(gè)常量當(dāng)前值分別為2、4、0、1即當(dāng)前處于 2.4.0 的預(yù)發(fā)布開(kāi)發(fā)階段這四個(gè)常量被組裝進(jìn)TockAttributesKernelVersion結(jié)構(gòu)體并通過(guò)#[cfg_attr(target_os none, unsafe(link_section .tock.attr.kernel_version))]放入鏈接腳本指定的.tock.attr.kernel_version段該結(jié)構(gòu)體遵循 Tock Kernel Attributes 格式tlv_type: 0x0103tlv_len: 8供引導(dǎo)加載程序、工具鏈與應(yīng)用程序校驗(yàn)內(nèi)核版本與自身應(yīng)用的兼容性。從源碼可以看出KERNEL_PRERELEASE_VERSION為0表示正式發(fā)布非0表示開(kāi)發(fā)版本應(yīng)用或工具還可以利用它依賴(lài)尚未進(jìn)入任何發(fā)布版本的內(nèi)核特性。四、穩(wěn)定化一個(gè) Syscall DriverStabilizing a Syscall Driver4.1 穩(wěn)定化的含義與保證范圍Tock 維護(hù)一份**已穩(wěn)定系統(tǒng)調(diào)用驅(qū)動(dòng)stabilized syscall drivers**清單這些驅(qū)動(dòng)實(shí)現(xiàn)SyscallDrivertrait通常位于 capsules 中。穩(wěn)定化的核心承諾是在相同主版本號(hào)major version的后續(xù)內(nèi)核版本中Tock 保證不會(huì)破壞這些已穩(wěn)定驅(qū)動(dòng)的接口。這意味著使用某個(gè)已穩(wěn)定系統(tǒng)調(diào)用驅(qū)動(dòng)的應(yīng)用程序在相同主版本的內(nèi)核上可以繼續(xù)正常工作。同時(shí)Tock 并不禁止在同一主版本內(nèi)擴(kuò)展已穩(wěn)定接口——允許添加新功能或修復(fù) bug只要不破壞向后兼容性。需要特別注意的是該穩(wěn)定性保證獨(dú)立于系統(tǒng)調(diào)用接口即command、allow、schedule等 ABI 本身的穩(wěn)定性?xún)烧呤遣煌瑢用娴某兄Z。4.2 穩(wěn)定化流程Syscall Driver Stabilization Process一個(gè)驅(qū)動(dòng)由其driver number唯一標(biāo)識(shí)的穩(wěn)定化遵循以下流程文檔完備該驅(qū)動(dòng)必須在 doc/syscalls 目錄下?lián)碛型暾慕涌谖臋n如 00001_console.md、00000_alarm.md 等提出穩(wěn)定化 PRTock 開(kāi)發(fā)者通過(guò)創(chuàng)建 Pull Request 提出將某個(gè)特定驅(qū)動(dòng)以其 driver number 和上游 Tock 倉(cāng)庫(kù)中的源碼標(biāo)識(shí)穩(wěn)定化PR 需要把該驅(qū)動(dòng)移入capsules/corecrate并在 doc/syscalls/README.md 的穩(wěn)定化列中標(biāo)上 ?表示待觀(guān)察P-Significant 評(píng)審穩(wěn)定化 PR 始終被標(biāo)記為P-Significant這要求核心工作組支持該穩(wěn)定化四個(gè)月觀(guān)察期該驅(qū)動(dòng)的接口必須在四個(gè)月內(nèi)保持不變。這段時(shí)間可以從穩(wěn)定化流程開(kāi)始之前的某個(gè)時(shí)間點(diǎn)算起變更即重置如果觀(guān)察期內(nèi)接口發(fā)生變更等待期重新開(kāi)始計(jì)算。驅(qū)動(dòng)在此期間還必須經(jīng)過(guò)合理的測(cè)試標(biāo)記穩(wěn)定觀(guān)察期結(jié)束后在下一次 Tock 主版本或小版本發(fā)布時(shí)將 doc/syscalls/README.md 穩(wěn)定化列中的 ? 更新為該 Tock 發(fā)布版本號(hào)即完成穩(wěn)定化標(biāo)記。4.3 穩(wěn)定化狀態(tài)的倉(cāng)庫(kù)證據(jù)doc/syscalls/README.md 是穩(wěn)定化狀態(tài)的權(quán)威記錄其中每個(gè)驅(qū)動(dòng)表格都帶有一列穩(wěn)定性標(biāo)記列該文件頭部注釋說(shuō)明 2.0 列表示該驅(qū)動(dòng)是否已在 Tock 2.0 發(fā)布中穩(wěn)定化? 表示穩(wěn)定。以當(dāng)前倉(cāng)庫(kù)為例已穩(wěn)定化的驅(qū)動(dòng)包括2.0Driver Number驅(qū)動(dòng)說(shuō)明?0x00000Alarm用戶(hù)態(tài)定時(shí)器?0x00001ConsoleUART 控制臺(tái)?0x00002LED控制板載 LED?0x00003Button讀取按鍵中斷?0x00005ADC模數(shù)轉(zhuǎn)換采樣?0x60000Ambient Temp.環(huán)境溫度?0x60001Humidity濕度傳感器?0x60002Luminance環(huán)境光傳感器而未穩(wěn)定化的驅(qū)動(dòng)如 0x00004 GPIO、0x00010 PWM、0x20000 UART 等在該列中留空等待后續(xù)版本按上述流程逐步推進(jìn)。被穩(wěn)定化的驅(qū)動(dòng)會(huì)進(jìn)入capsules/corecrate。例如 Console 驅(qū)動(dòng)的SyscallDriver實(shí)現(xiàn)位于 capsules/core/src/console.rs其配套的接口文檔為 doc/syscalls/00001_console.md。這種「文檔 源碼 穩(wěn)定化標(biāo)記」三位一體的結(jié)構(gòu)保證了穩(wěn)定化承諾既可被審計(jì)文檔與標(biāo)記可追蹤又可被實(shí)現(xiàn)源碼可驗(yàn)證。五、維護(hù)者的日常工作與協(xié)作機(jī)制除發(fā)布與穩(wěn)定化外核心工作組的日常維護(hù)還包括代碼評(píng)審核心組成員需要按比例評(píng)審新 Pull Request確保代碼風(fēng)格與結(jié)構(gòu)的一致性可參考 doc/CodeReview.md 與 doc/Style.md測(cè)試參與成員需在發(fā)布前參與 Tock 的測(cè)試設(shè)計(jì)決策對(duì)重大設(shè)計(jì)變更提供意見(jiàn)與輸入文檔與工具鏈項(xiàng)目通過(guò) doc/CodeGoals.md、doc/SecurityProtocol.md 等文檔約定長(zhǎng)期目標(biāo)與安全流程并通過(guò) tools/ 下的 CI、license-checker、qemu-runner 等工具鏈支撐持續(xù)集成與質(zhì)量保障?？偨Y(jié)Tock 的維護(hù)體系可以概括為三條主線(xiàn)規(guī)劃通過(guò)年度 Tock World 研討會(huì)與每周核心工作組會(huì)議確定長(zhǎng)期方向發(fā)布以release-blocker驅(qū)動(dòng)的里程碑策略配合release/$major.$minor分支、annotated tag 和「KERNEL 版本常量 Cargo.toml 版本 CHANGELOG」三處同步更新的機(jī)制形成可重復(fù)、可審計(jì)的發(fā)布閉環(huán)穩(wěn)定化以「完整文檔 四個(gè)月無(wú)變更觀(guān)察期 P-Significant評(píng)審 版本號(hào)標(biāo)記」流程為用戶(hù)態(tài)應(yīng)用提供同主版本內(nèi)的接口兼容保證。對(duì)于想要參與 Tock 維護(hù)的開(kāi)發(fā)者最實(shí)際的切入點(diǎn)有兩個(gè)一是認(rèn)領(lǐng)某塊開(kāi)發(fā)板的發(fā)布測(cè)試復(fù)制上一輪清單并逐項(xiàng)驗(yàn)證二是通過(guò)提交穩(wěn)定化 PR 推動(dòng)某個(gè)尚未穩(wěn)定的系統(tǒng)調(diào)用驅(qū)動(dòng)如 GPIO、UART進(jìn)入capsules/core并完成四個(gè)月觀(guān)察期。這兩條路徑都完全基于本文所描述的、由 doc/Maintenance.md 定義并在倉(cāng)庫(kù)源碼中落地的流程。贊分享操作系統(tǒng)嵌入式嵌入式OS【免費(fèi)下載鏈接】tockA secure embedded operating system for microcontrollers項(xiàng)目地址https://gitcode.com/gh_mirrors/to/tock點(diǎn)擊查看免費(fèi)下載相關(guān)推薦Sunshine 穩(wěn)定版發(fā)布全流程從自動(dòng) Pre-release 到多源發(fā)布的維護(hù)者操作指南Sunshine 穩(wěn)定版發(fā)布全流程從自動(dòng) Pre release 到多源發(fā)布的維護(hù)者操作指南 Sunshine 的發(fā)布體系采用預(yù)發(fā)布全自動(dòng) 穩(wěn)定版人工確音視頻后端UVR Ultimate Vocal Remover 人聲分離教程5 分鐘做出 KTV 伴奏UVR Ultimate Vocal Remover 人聲分離教程5 分鐘做出 KTV 伴奏 ? 翻唱缺伴奏、播客想去 BGM、KTV 想提取純?nèi)寺昒l音頻處理人工智能Jasmine 版本發(fā)布全流程指南從 SemVer 規(guī)劃到 npm 發(fā)布與 GitHub ReleaseJasmine 版本發(fā)布全流程指南從 SemVer 規(guī)劃到 npm 發(fā)布與 GitHub Release 本篇指南面向 Jasmine 的維護(hù)者Core M測(cè)試質(zhì)量保障上一篇cpulimit安裝與配置5分鐘快速部署完整教程 下一篇72小時(shí)限時(shí)開(kāi)源SpringBoot3Vue3全棧開(kāi)發(fā)腳手架從0到1搭建企業(yè)級(jí)應(yīng)用架構(gòu)創(chuàng)作聲明：本文部分內(nèi)容由AI輔助生成（AIGC），僅供參考