EDBT 2026 Demo / reviewers in the wild / expert
Adin Ackerman
dblp:429/2180
· DBLP profile ↗
1ranked-venue papers
0as first author
1since 2021 · last 2026
0009-0006-5335-7523ORCID · reported
Domains — the database's venue-derived domains; a paper can count in several
Systems, architecture and hardware · 1 · 1 since 2021Software engineering, systems software and programming languages · 1 · 1 since 2021
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Software engineering, system software, and programming languages
1 paper |
Operating systems · 50% Programming languages and type systems · 50% | |
| Computer architecture, parallel and distributed computing, and storage systems
1 paper |
Hardware accelerators and domain-specific architectures · 100% |
Topics — the 3 heaviest of 3, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Operating systems › i/o › i/o subsystem
device drivers |
1.0 | 1 | 2026 | Rage Against the State Machine: Type-Stated Hardware Peripherals for Increased Driver Correctness · ASPLOS (2) 2026 |
Programming languages and type systems
type systems |
1.0 | 1 | 2026 | Rage Against the State Machine: Type-Stated Hardware Peripherals for Increased Driver Correctness · ASPLOS (2) 2026 |
Hardware accelerators and domain-specific architectures
hardware-software interface |
0.3 | 1 | 2026 | Rage Against the State Machine: Type-Stated Hardware Peripherals for Increased Driver Correctness · ASPLOS (2) 2026 |
Methods — techniques the papers use, named apart from their topics
typestate analysis · 1.0type-state analysis · 1.0
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2026 | Rage Against the State Machine: Type-Stated Hardware Peripherals for Increased Driver CorrectnessabstractHardware provides driver authors both a strict specification of the operations a driver is allowed to do, and a highly permissive interface full of operations a driver can do. Authoring drivers that adhere to the provided hardware device protocol is challenged by dynamic definitions of what a driver should do based on the hardware's state. This is further complicated by increasingly capable hardware which may transition between states concurrently and independently from the software driver. Tyler Potyondy, Anthony Tarbinian, Leon Schuermann, Eric Mugnier, Adin Ackerman, Amit Levy 0001, Pat Pannuto |
ASPLOS (2) | 5 |