Exécutez n'importe quel Skill dans Manus
en un clic

Exécutez n'importe quel Skill dans Manus en un clic

device-driver-development

Étoiles5

Forks0

Mis à jour14 juillet 2026 à 04:52

Use when developing, reviewing, debugging, porting, or engineering Linux kernel device drivers, kernel modules, device tree bindings, bus clients, subsystem drivers, DMA/IRQ/memory paths, userspace interfaces, or hardware bring-up plans.

Installation

Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.

Exécuter dans Manus

Source

oghie

oghie/skillsets

Ouvrir le dépôt GitHub Voir les dépôts du créateur

Téléchargement

Exécuter dans Manus

Métiers associésSOC

Basé sur la classification professionnelle SOC

Développeurs de logicielsProfessions informatiques et mathématiques·SOC 15-1252

Explorateur de fichiers

16 fichiers

SKILL.md

readonly

name	device-driver-development
description	Use when developing, reviewing, debugging, porting, or engineering Linux kernel device drivers, kernel modules, device tree bindings, bus clients, subsystem drivers, DMA/IRQ/memory paths, userspace interfaces, or hardware bring-up plans.
version	0.1.0
author	oghie
license	MIT
metadata	{"hermes":{"tags":["software-development","linux","kernel","drivers","embedded"],"source":"https://github.com/oghie/skillsets"}}

Device Driver Development

Core Rule

Treat every driver task as hardware contract engineering: identify the kernel version, hardware bus, subsystem owner, execution context, lifetime model, and userspace ABI before writing code.

Knowledge Grounding

Use references/knowledge-map.md for the driver domain map and conceptual model.
Treat API details as version-sensitive; verify callback signatures, helpers, and bindings against the active kernel tree or current kernel docs.

First Pass

Classify the device: char, platform, I2C, SPI, regmap, IIO, GPIO, IRQ controller, input, RTC, PWM, regulator, framebuffer, or NIC.
Identify interface surfaces: /dev, sysfs, debugfs, ioctl, mmap, netdev, IIO buffers, input events, DT binding, or kernel consumer API.
Choose probe/remove lifetime: prefer devm_*, explicit unwind only when ordering or shared state requires it.
Decide concurrency boundaries: process context, atomic context, IRQ top half, threaded IRQ, workqueue, timer, DMA callback.
Define evidence needed: datasheet registers, bus transaction examples, DT node, logs, scope/logic-analyzer traces, and test plan.

Required Reads By Task

New driver or hardware bring-up: tasks/bringup-workflow.md.
Implementing subsystem callbacks: tasks/implementation-patterns.md and references/subsystem-matrix.md.
Memory, MMIO, mmap, DMA, IRQ, locking: references/kernel-engineering-principles.md.
Debugging, validation, or intermittent behavior: tasks/debugging-testing.md.
Toolchain, QEMU, KGDB, bpftrace, Smatch, Coccinelle, Syzkaller, Bootlin: references/tooling-matrix.md.
Auditable engineering flow: tasks/step-verify-workflow.md.
Upstream-ready patches or long-term maintenance: tasks/upstream-maintenance.md.
Final review before handoff: references/review-checklist.md.

Design Heuristics

Prefer an existing kernel subsystem over a private char driver when the device matches a framework.
Keep policy in userspace and mechanism in kernel; avoid inventing ABI without necessity.
Never sleep in atomic context; never hold spinlocks across bus calls that may sleep.
Use copy_{to,from}_user() only at ABI boundaries and handle partial copy/error paths.
For MMIO use devm_ioremap_resource() plus accessor APIs; do not dereference __iomem.
For register devices on I2C/SPI, consider regmap before custom read/write helpers.
For DT, model hardware, not Linux driver internals; document compatibles and supplies/clocks/IRQs/GPIOs.

Script Helpers

Run scripts/driver_static_scan.py <path> for heuristic review of C, Kconfig, Makefile, DTS, and binding files.
Run scripts/module_smoke_build.sh <module-dir> [kernel-build-dir] for out-of-tree build smoke checks.
Run scripts/tooling_probe.sh to inspect local build, static-analysis, tracing, fuzzing, QEMU, and KGDB tool availability.

Verification Gate

Build with warnings enabled and, when available, sparse, Smatch, Coccinelle, checkpatch.pl, dt_binding_check, and subsystem selftests.
Test load/unload, probe/remove failure paths, hot/unplug or unbind where applicable, suspend/resume if resources are power-managed.
Capture runtime evidence: dmesg, /proc/interrupts, sysfs state, tracepoints/ftrace/bpftrace, bus transactions, and userspace API results.
Use QEMU/KGDB for isolated crash reproduction and Syzkaller for fuzzable ABI surfaces when practical.
Do not claim correctness from compilation alone; tie each claim to a code path, runtime observation, or documented subsystem contract.

Output Standard

When answering, name assumptions, selected subsystem, key APIs, file layout, validation commands, and residual hardware risks. If source evidence is missing, say what must be measured or read next.

Plus depuis ce dépôt

même dépôt

cyber-security-operations

oghie/skillsets

Use when performing cybersecurity operations - offensive or defensive - including threat detection and hunting, SOC operations, incident response, digital forensics and DFIR, malware analysis and reverse engineering, threat intelligence, cloud/container/network/application/API security, identity-access and zero-trust, OT/ICS and endpoint security, vulnerability and supply-chain management, DevSecOps, cryptography, AI security, compliance and governance, and red-team or penetration testing under signed rules of engagement; routes to one of 800+ technique playbooks mapped to MITRE ATT&CK, D3FEND, and NIST CSF.

2026-07-155

android-offsec

oghie/skillsets

Android device offensive security, forensic extraction, and mobile app exploitation. Use this whenever the user needs to: break into or bypass the lock screen of an Android phone, extract data from a seized Android device for evidence, analyze or reverse-engineer an APK to find vulnerabilities, intercept communications on an Android device, exploit Android apps via deeplinks, steal crypto wallets or app data, set up rogue WiFi to target a phone, or plan any mobile device investigation or penetration test. Also trigger when the user mentions Android forensics, mobile pentesting, law enforcement phone extraction, device exploitation, WhatsApp or Telegram extraction from a phone, Android app reversing, CVE research for Android, or needing a chain of custody for mobile evidence. Even if the user describes the scenario casually or in another language, if they need to gain access to or pull data from an Android phone, use this skill.

2026-07-155

academic-research-journal

oghie/skillsets

Use when evaluating, designing, drafting, revising, stress-testing, or preparing academic articles, empirical research reports, literature reviews, systematic reviews, meta-analyses, journal submissions, reviewer responses, research methods, sampling, measurement, analysis, publication readiness, or citation/source audits.

2026-07-145

data-architect-engineering

oghie/skillsets

Use when designing, reviewing, modifying, migrating, optimizing, securing, operating, troubleshooting, or decommissioning data architectures across data model exploration, SQL, ISO SQL conformance, NoSQL, vector, graph, document, time-series, NewSQL, search, in-memory, SQLite, CDC/Debezium, DBMS storage/query/recovery internals, database incident prevention, hardware acceleration, cache, big-data, lakehouse, and warehouse systems.

2026-07-145

realtime-systems-coding

oghie/skillsets

Use when designing, implementing, reviewing, debugging, testing, profiling, or porting concurrent, parallel, distributed, high-performance, network dataplane, kernel-bypass, or real-time software, including locks, semaphores, monitors, MPI, CSP rendezvous, DPDK, VPP, eBPF, XDP, AF_XDP, SR-IOV, RSS, RoCEv2/RDMA, RMS/EDF, priority inversion, and environment selection from silicon to edge.

2026-07-145

software-architecture-engineering-uap

oghie/skillsets

Use when designing, evaluating, documenting, modernizing, reviewing, refactoring, or implementing software architecture and code-level structure, including requirements, context, architecture style selection, microservices patterns, clean code, code smells, Rust crate/library API architecture, Cargo feature/MSRV/SemVer policy, unsafe/FFI/no_std/library testing, modularity, views, NFR tactics, IAM/auth, security patterns, cost estimation, architecture-as-code fitness functions, ADR/RFC work, and engineering execution plans.

2026-07-145

name	device-driver-development
description	Use when developing, reviewing, debugging, porting, or engineering Linux kernel device drivers, kernel modules, device tree bindings, bus clients, subsystem drivers, DMA/IRQ/memory paths, userspace interfaces, or hardware bring-up plans.
version	0.1.0
author	oghie
license	MIT
metadata	{"hermes":{"tags":["software-development","linux","kernel","drivers","embedded"],"source":"https://github.com/oghie/skillsets"}}

Device Driver Development

Core Rule

Treat every driver task as hardware contract engineering: identify the kernel version, hardware bus, subsystem owner, execution context, lifetime model, and userspace ABI before writing code.

Knowledge Grounding

Use references/knowledge-map.md for the driver domain map and conceptual model.
Treat API details as version-sensitive; verify callback signatures, helpers, and bindings against the active kernel tree or current kernel docs.

First Pass

Classify the device: char, platform, I2C, SPI, regmap, IIO, GPIO, IRQ controller, input, RTC, PWM, regulator, framebuffer, or NIC.
Identify interface surfaces: /dev, sysfs, debugfs, ioctl, mmap, netdev, IIO buffers, input events, DT binding, or kernel consumer API.
Choose probe/remove lifetime: prefer devm_*, explicit unwind only when ordering or shared state requires it.
Decide concurrency boundaries: process context, atomic context, IRQ top half, threaded IRQ, workqueue, timer, DMA callback.
Define evidence needed: datasheet registers, bus transaction examples, DT node, logs, scope/logic-analyzer traces, and test plan.

Required Reads By Task

New driver or hardware bring-up: tasks/bringup-workflow.md.
Implementing subsystem callbacks: tasks/implementation-patterns.md and references/subsystem-matrix.md.
Memory, MMIO, mmap, DMA, IRQ, locking: references/kernel-engineering-principles.md.
Debugging, validation, or intermittent behavior: tasks/debugging-testing.md.
Toolchain, QEMU, KGDB, bpftrace, Smatch, Coccinelle, Syzkaller, Bootlin: references/tooling-matrix.md.
Auditable engineering flow: tasks/step-verify-workflow.md.
Upstream-ready patches or long-term maintenance: tasks/upstream-maintenance.md.
Final review before handoff: references/review-checklist.md.

Design Heuristics

Prefer an existing kernel subsystem over a private char driver when the device matches a framework.
Keep policy in userspace and mechanism in kernel; avoid inventing ABI without necessity.
Never sleep in atomic context; never hold spinlocks across bus calls that may sleep.
Use copy_{to,from}_user() only at ABI boundaries and handle partial copy/error paths.
For MMIO use devm_ioremap_resource() plus accessor APIs; do not dereference __iomem.
For register devices on I2C/SPI, consider regmap before custom read/write helpers.
For DT, model hardware, not Linux driver internals; document compatibles and supplies/clocks/IRQs/GPIOs.

Script Helpers

Run scripts/driver_static_scan.py <path> for heuristic review of C, Kconfig, Makefile, DTS, and binding files.
Run scripts/module_smoke_build.sh <module-dir> [kernel-build-dir] for out-of-tree build smoke checks.
Run scripts/tooling_probe.sh to inspect local build, static-analysis, tracing, fuzzing, QEMU, and KGDB tool availability.

Verification Gate

Build with warnings enabled and, when available, sparse, Smatch, Coccinelle, checkpatch.pl, dt_binding_check, and subsystem selftests.
Test load/unload, probe/remove failure paths, hot/unplug or unbind where applicable, suspend/resume if resources are power-managed.
Capture runtime evidence: dmesg, /proc/interrupts, sysfs state, tracepoints/ftrace/bpftrace, bus transactions, and userspace API results.
Use QEMU/KGDB for isolated crash reproduction and Syzkaller for fuzzable ABI surfaces when practical.
Do not claim correctness from compilation alone; tie each claim to a code path, runtime observation, or documented subsystem contract.

Output Standard

When answering, name assumptions, selected subsystem, key APIs, file layout, validation commands, and residual hardware risks. If source evidence is missing, say what must be measured or read next.