System-Specific Interpreters Make Megasystems Friendlier

2025-05-02 0 0 512.72KB 8 页 10玖币
侵权投诉
1
System-Specific Interpreters Make Megasystems Friendlier
MATTHEW SOTOUDEH,Stanford University, USA
Modern operating systems, browsers, and oce suites have become megasystems built on millions of lines
of code. Their sheer size can intimidate even experienced users and programmers away from attempting
to understand and modify the software running on their machines. This paper introduces system-specic
interpreters (SSIs) as a tool to help users regain knowledge of and control over megasystems. SSIs directly
execute individual modules of a megasystem in a
gdb
-like environment without forcing the user to build, run,
and trace the entire system. A prototype framework to help write SSIs is described in this paper and available
for download at https://github.com/matthewsot/ssi-live22.
1 INTRODUCTION
Ballooning user expectations have caused computer systems to grow in size and complexity over
time. Operating systems, web browsers, oce suites, compilers, and even websites are routinely
hundreds of thousands or even millions of lines of code across a variety of programming languages.
These megasystems are extremely useful, surprisingly dependable, and often free software. But
their sheer size makes it increasingly dicult for users and hobbyist programmers to understand
and modify them. Even compiling some megasystems, such as the Linux kernel, can be a surprisingly
challenging task. Such barriers represent an unfortunate bottleneck through which even reasonably
motivated and skilled users are prevented from understanding and exercising control over the
software that has become necessary for their daily lives.
This paper proposes the development and use of system-specic interpreters (SSIs) to help users
understand and modify portions of such megasystems. The key insight is that, from the perspective
of any given module of the larger system, the rest of the system exposes a domain-specic language
in which the module is written. Directly building an interpreter (the SSI) for that language allows
the user to run individual modules, les, and functions without having to wait for the system to
build, construct inputs triggering the code in question, or insert tracing code.
In fact, programmers already build such SSIs informally in their heads when attempting to
understand megasystems. We usually start at some interesting part of the code, e.g., a particular
device driver, and read it without knowing exactly how it is called by the overall megasystem or
what all of the functions it calls do. Over time, an informal mental model of this interface between
the module and megasystem is formed to enable such underconstrained reasoning.
Our key idea is to formalize and mechanize this mental model of the interface between the module
and the rest of the system. By giving users the tools to formally specify (as an SSI) their previously
informal model of the system–module interface, the cognitive burden of remembering a large
model is reduced. Executing code against this model via the SSI helps users nd inconsistencies or
inaccuracies in their mental model of the system.
We describe a framework that makes writing SSIs easier. The key idea is to separate imple-
mentation of language-level syntax and semantics from system-level syntax and semantics. Once
written, SSIs simulate execution of a module in isolation, similar to a unit test. The user interacts
with the SSI’s
gdb
-style interface to trace and modify intermediate states of the execution. After
modifying the code, the SSI can be re-run to check if the modication had the desired eect. By
directly interpreting the specic code that the programmer cares about, SSIs are a rst step towards
bringing the power of live programming and REPL environments to bear on the unique challenges
of lower-level systems code.
Author’s address: Matthew Sotoudeh, Stanford University, Stanford, CA, USA, sotoudeh@stanford.edu.
arXiv:2210.09460v1 [cs.SE] 17 Oct 2022
1:2 Mahew Sotoudeh
Linux
Build Run
Trace Understand
(a) Without SSI
Linux +SSI
Understand
(b) With SSI
Fig. 1. Poking at megasystem code usually involves figuring out how to: (i) build the system, (ii) execute it
with the right inputs to reach the desired code, and (iii) trace the eects of the code. None of these steps are
easy in most modern megasystems. SSIs execute individual modules of a megasystem within an interpreter
environment, allowing users to skip directly to the key poking-and-understanding phase of the cycle.
2 CASE STUDY
Consider a curious Jane Doe. One day, she is using a Raspberry Pi to control a light strip and
becomes interested in how the kernel’s GPIO driver works. She pulls up the Linux source code,
and nds the relevant
pinctrl-bcm2835
driver code excerpted in Figure 2a. Reading the code, she
notices that the broader Linux kernel provides essentially a domain-specic language (DSL) to the
driver code. This DSL includes, for example, commands to remap (
devm_ioremap_resource
) or
write to (
writel
) memory-mapped input-output (MMIO) addresses. The DSL exposed by the kernel
actually spans multiple real languages, e.g., MMIO addresses are implicitly read from a device tree
source include (DTSI) le that gets compiled into the kernel at build time.
Jane quickly recalls why playing with megasystem codebases is a daunting task. Traditional
debugging tools like
gdb
require her to build and run the code, but Jane has only ever used a
pre-built kernel. Even if she could build the kernel or driver, Jane may not always have immediate
access to a Raspberry Pi to run the code on. Even if all of those issues were worked out, Jane would
have to spend time writing a test program that correctly invokes the right combination of syscalls
to trigger the driver code she is trying to understand, and then somehow gure out what the driver
code is actually doing to the hardware, i.e., what MMIO addresses are actually being written to at
each point in the program and with what values. Unless Jane wants to try and understand the code
entirely in her head, without the benet of actually running it like code to see what it does, she must
solve all of these problems before even beginning to understand the code.
2.1 Using a System-Specific Interpreter
Suppose instead that Jane had a system-specic interpreter (SSI) for this device driver, as shown
in Figure 2b. The SSI loads the driver source code, then provides a
gdb
-like REPL interface to a
simulated instance of the driver. Jane can ask it to load the driver and run dierent driver operations
in a simulated environment. She can trace, set breakpoints, and step-through the driver code.
Figure 2b shows how Jane can use the SSI to print out the arguments of every call to
writel
, and
set a breakpoint to inspect the values of local variables.
Because the SSI is directly interpreting the driver code itself, not the entire Linux kernel, it starts
and executes quickly. If Jane later modies the code, she can immediately re-run the SSI to verify
it produces the desired behavior. Only once Jane has understood the driver code and made any
desired modications might she need to worry about building and loading the driver. The SSI allows
her to separate concerns: understanding and modifying an individual module in the megasystem
without rst understanding the entire megasystem and associated build system.
摘要:

1System-SpecificInterpretersMakeMegasystemsFriendlierMATTHEWSOTOUDEH,StanfordUniversity,USAModernoperatingsystems,browsers,andofficesuiteshavebecomemegasystemsbuiltonmillionsoflinesofcode.Theirsheersizecanintimidateevenexperiencedusersandprogrammersawayfromattemptingtounderstandandmodifythesoftwarer...

展开>> 收起<<
System-Specific Interpreters Make Megasystems Friendlier.pdf

共8页,预览2页

还剩页未读, 继续阅读

声明:本站为文档C2C交易模式,即用户上传的文档直接被用户下载,本站只是中间服务平台,本站所有文档下载所得的收益归上传人(含作者)所有。玖贝云文库仅提供信息存储空间,仅对用户上传内容的表现方式做保护处理,对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私,请立即通知玖贝云文库,我们立即给予删除!
分类:图书资源 价格:10玖币 属性:8 页 大小:512.72KB 格式:PDF 时间:2025-05-02

开通VIP享超值会员特权

  • 多端同步记录
  • 高速下载文档
  • 免费文档工具
  • 分享文档赚钱
  • 每日登录抽奖
  • 优质衍生服务
/ 8
客服
关注