Browser extensions are kernel modules for browsers
Back in October, after a few weeks of working on the River Trail Firefox extension, I had a trite epiphany: if a browser is an OS, then extensions are kernel modules for that OS.
When I realized that this was even possible, I excitedly told an acquaintance:
We could have implemented everything the library does as part of the extension, too, but there’s no need. Keeping the extension small is desirable, since it’s running in a privileged context, and keeping the amount of privileged code small means that there are, we hope, fewer bugs that can do bad things.
This lack of assumptions can give us modularity and the ability to reuse components for unforeseen purposes. OpenCL doesn’t have to target that particular graphics driver; it can, at least in theory, interact with any graphics driver that presents a certain interface. Conversely, the kernel-level driver may be generic enough (or robust enough) to handle all kinds of stuff coming from user space, not just OpenCL. Coming back to the analogy with browsers and browser extensions, the River Trail library could talk to, for instance, WebCL instead of the River Trail extension. And, although this this wasn’t the originally intended purpose, it’s absolutely possible for JS libraries other than the River Trail library to talk to to the River Trail extension and use it however they want.
Thanks to Dan Luu, Darius Bacon, Stan Schwertly, Eiríkr Åsheim, Colin Barrett, Jesse Ruderman, Greg Pfeil, Julia Evans, and Jamey Sharp for reading drafts of this post. The last part in particular owes a huge debt to Jamey!