Driver Development Kit DDK and Vendor Workflow
summary
Qualcomm migrates its external kernel modules for about 50 out-of-tree modules from build.sh to Google’s Kleaf framework and the Driver Development Kit (DDK), replacing Kbuild/make with a replaced build.sh with Bazel build flow and Bazel/Starlark module definitions. DDK enforces sandboxed kernel headers, which reveals accidental use of private headers, reduces build-definition boilerplate (about cut build lines by ~50%), adds graph queries and profiling, but forces learning Bazel, breaks env-var hacks, and makes sandbox cleanup complicate debugging.
AI-written summary · about
chapters (12)
- 0:00Introduction to DDK
- 1:04Previous build workflow
- 2:49DDK integration process
- 4:13Pros of DDK adoption
- 7:07Cons and challenges
- 8:11Debugging with DDK
- 9:07Config snippets in DDK
- 10:16Feature flags and platforms
- 11:47Non-Android targets with CLE
- 12:21Upstreaming and collisions
- 13:47Learning resources for DDK
- 14:29Conclusion and Q&A
related talks
14mGKI Experience
09mCuttlefish and Kernel Dev
37mA Developer's Diary: The Trials and Triumphs of Maintaining Devboards in AOSP
38mBuilding Self Driving Cars with Bazel + Q&A
33mAndroid Boot, DRTM, UKIs
08mKernel work group assignee
41mUnifying Android and Mainline Kernel Graphics Stack
26mBootloops & Coffee: The Daily Grind of an AOSP Developer