three decades: ◦ The Internet ◦ Distributed version control ◦ Open source • And of course, Moore’s Law dominated hardware • Aside: revolutions like cloud computing are the confluence of all of these
exclusively as increased transistor density, Moore’s Law holds at a greatly slowed pace — but at outsized cost • Moore’s Law has ceased to exist as an economic law • But is there another way of looking at it?
costs of aircraft manufacturing, finding that the cost dropped with experience • Over time, when volume doubled, unit costs dropped by 10-15% • This phenomenon has been observed in other technological domains • In 2013, Jessika Trancik et al. found Wright’s Law to hold better predictive power for transistor cost than Moore’s Law! • Wright’s Law seems to hold, especially for older process nodes
hold, compute will be economically viable in more and more places that were previously confined to hard logic • This is true even on die, where chiplets have made it easier than ever to build a heterogeneous system — and where mixed process nodes have demanded more sophistication • Quick, how many cores are on your server? (Don’t forget the hidden ones!)
many more places means software in many more places, many of them hard to get to! • Historically, we have referred to the software that’s hard to get to by its own malapropism: firmware • More compute means much more of this lowest level system software, but security and multi-tenancy cannot be an afterthought! • We need to rethink our system software; could software revolutions past guide to firmware revolutions future?
is, at some level, special purpose • These systems are much less balanced than our general-purpose systems — with much less memory and/or non-volatile storage • The overhead of dynamic environments (Java, Go, Python, etc.) is unacceptably high — and the development benefit questionable • Languages traditional used in this domain — C and C++ — both have well-known challenges around safety and security • But why are safety and security important?
necessary for composability! • Composability fuels open source: when composability is absent, source code may serve as blueprint and literature -- but not building block • Open source is itself the most important coming revolution in firmware... • But for the open source revolution to gain purchase within firmware, we must have open, safe, secure, composable components • Enter Rust, and its killer feature...
many respects, but one that may be underappreciated is its ability to not depend on its own standard library • Much of what is valuable about the language — sum types, ownership model, traits, hygienic macros — is in core, not the standard library • Crates marked “no_std” will not perform any heap allocations — and any such allocation is a compile-time error! • But no_std crates can depend on other no_std crates — lending real composability to a domain for whom it has been entirely deprived
small ◦ E.g., at Oxide, we are developing a message-passing, memory protected system entirely in Rust (Rust microkernel, Rust tasks); minimal systems are 30K — and entirely realistic ones are < 200K! • no_std is without real precedent in other languages or environments; it allows Rust to be put in essentially arbitrarily confined contexts • Rust is the first language since C to meaningfully exist at the boundary of hardware and systems software!
to hold, resulting in more compute in more places — bringing with it more firmware! • We know from the last three decades that open source is essential -- but it needs composability to become non-linear • Rust brings new levels of composability to firmware • We fully expect many more open source, de novo hardware-facing Rust-based systems — and thanks to no_std they will be able to leverage one another, greatly accelerating open source firmware!
bcantrill
sugamasao
chanyou0311
miu_crescent
fullkaiten
eventhub
sansantech
tacck
yuki_ink
salaboy
kakehashi
nssv
estie
tanoku
maggiecrowley
eileencodes
chrislema
addyosmani
afnizarnur
marktimemedia
caitiem20
kastner
geoffreycrofte
samanthasiow
