Demo Data from EDBT 2026 / reviewers in the wild / expert
Con McGarvey
dblp:61/3267
· DBLP profile ↗
3ranked-venue papers
0as first author
0since 2021 · last 2011
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 2Systems, architecture and hardware · 1
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 |
Program analysis · 46% Operating systems · 46% Program verification · 7% | |
| Computer architecture, parallel and distributed computing, and storage systems
1 paper |
Electronic design automation · 77% Embedded and real-time systems · 23% |
Topics — the 6 heaviest of 7, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Electronic design automation › hardware verification and test
hardware verification |
0.1 | 1 | 2011 | Formalizing hardware/software interface specifications · ASE 2011 |
Program analysis › error detection
API usage error detection |
0.1 | 1 | 2006 | Thorough static analysis of device drivers · EuroSys 2006 |
Operating systems › i/o › i/o subsystem
device drivers |
0.1 | 1 | 2006 | Thorough static analysis of device drivers · EuroSys 2006 |
Operating systems › i/o › i/o subsystem › device drivers
device driver verification |
0.1 | 1 | 2006 | Thorough static analysis of device drivers · EuroSys 2006 |
Program analysis
static analysis |
0.1 | 1 | 2006 | Thorough static analysis of device drivers · EuroSys 2006 |
Program verification
model checking |
0.0 | 1 | 2006 | Thorough static analysis of device drivers · EuroSys 2006 |
Methods — techniques the papers use, named apart from their topics
relative atomicity · 0.1formal specification · 0.1static analysis engine · 0.1API usage rules · 0.1
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2011 | Formalizing hardware/software interface specificationsabstractSoftware drivers are usually developed after hardware devices become available. This dependency can induce a long product cycle. Although co-simulation and co-verification techniques have been utilized to facilitate the driver development, Hardware/Software (HW/SW) interface models, as the test harnesses, are often challenging to specify. Such interface models should have formal semantics, be efficient for testing, and cover all HW/SW behaviors described by HW/SW interface protocols. We present an approach to formalizing HW/SW interface specifications, where we propose a semantic model, relative atomicity, to capture the concurrency model in HW/SW interfaces; demonstrate our approach via a realistic example; elaborate on how we have utilized this approach in device/driver development process; and discuss criteria for evaluating our formal specifications. We have detected fifteen issues in four English specifications. Furthermore, our formal specifications are readily useful as the test harnesses for co-verification, which has discovered twelve real bugs in five industrial driver programs. Juncao Li, Thomas Ball 0001, Vladimir Levin, Con McGarvey |
ASE | 5 |
| 2010 | An Automata-Theoretic Approach to Hardware/Software Co-verification
Juncao Li, Thomas Ball 0001, Vladimir Levin, Con McGarvey |
FASE | 5 |
| 2006 | Thorough static analysis of device driversabstractBugs in kernel-level device drivers cause 85% of the system crashes in the Windows XP operating system [44]. One of the sources of these errors is the complexity of the Windows driver API itself: programmers must master a complex set of rules about how to use the driver API in order to create drivers that are good clients of the kernel. We have built a static analysis engine that finds API usage errors in C programs. The Static Driver Verifier tool (SDV) uses this engine to find kernel API usage errors in a driver. SDV includes models of the OS and the environment of the device driver, and over sixty API usage rules. SDV is intended to be used by driver developers "out of the box." Thus, it has stringent requirements: (1) complete automation with no input from the user; (2) a low rate of false errors. We discuss the techniques used in SDV to meet these requirements, and empirical results from running SDV on over one hundred Windows device drivers. Thomas Ball 0001, Ella Bounimova, Byron Cook, Vladimir Levin, Jakob Lichtenberg, Con McGarvey, Bohus Ondrusek, Sriram K. Rajamani, Abdullah Ustuner |
EuroSys | 6 |