Balachandra Mirla

dblp:04/9257 · DBLP profile ↗
← Back
1ranked-venue papers
0as first author
0since 2021 · last 2011
—ORCID · none

Domains — the database's venue-derived domains; a paper can count in several

Systems, architecture and hardware · 1Software engineering, systems software and programming languages · 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
Operating systems · 77% Software maintenance and evolution · 23%
Computer architecture, parallel and distributed computing, and storage systems
1 paper
Electronic design automation · 100%

Topics — the 3 heaviest of 3, each with the papers that count most for it

TopicWeightPapersLastEvidence papers
Operating systems › i/o › i/o subsystem › device drivers
device driver reliability
0.112011
Improved device driver reliability through hardware verification reuse · ASPLOS 2011
Electronic design automation › hardware verification and test
hardware verification
0.112011
Improved device driver reliability through hardware verification reuse · ASPLOS 2011
Software maintenance and evolution
software cost reduction
0.012011
Improved device driver reliability through hardware verification reuse · ASPLOS 2011

Methods — techniques the papers use, named apart from their topics

hardware verification reuse · 0.2
YearPublicationVenuePosition
2011 Improved device driver reliability through hardware verification reuse
abstract
Faulty device drivers are a major source of operating system failures. We argue that the underlying cause of many driver faults is the separation of two highly-related tasks: device verification and driver development. These two tasks have a lot in common, and result in software that is conceptually and functionally similar, yet kept totally separate. The result is a particularly bad case of duplication of effort: the verification code is correct, but is discarded after the device has been manufactured; the driver code is inferior, but used in actual device operation. We claim that the two tasks, and the software they produce, can and should be unified, and this will result in drastic improvement of device-driver quality and reduction in the development cost and time to market.
Leonid Ryzhyk, John Keys, Balachandra Mirla, Arun Raghunath, Mona Vij, Gernot Heiser
ASPLOS3