Things Are Getting Rusty In Kernel Land

There is gathering momentum around the idea of adding Rust to the Linux kernel. Why exactly is that a big deal, and what does this mean for the rest of us? The Linux kernel has been just C and assembly for its entire lifetime. A big project like the kernel has a great deal of shared tooling around making its languages work, so adding another one is quite an undertaking. There’s also the project culture developed around the language choice. So why exactly are the grey-beards of kernel development even entertaining the idea of adding Rust? To answer in a single line, it’s because C was designed in 1971, to run on the minicomputers at Bell Labs. If you want to shoot yourself in the foot, C will hand you the loaded firearm.

On the other hand, if you want to write a kernel, C is a great language for doing low-level coding. Direct memory access? Yep. Inline assembly? Sure. Runs directly on the metal, with no garbage collection or virtual machines in the way? Absolutely. But all the things that make C great for kernel programming also make C dangerous for kernel programming.

Now I hear your collective keyboards clacking in consternation: “It’s possible to write safe C code!” Yes, yes it is possible. It’s just very easy to mess up, and when you mess up in a kernel, you have security vulnerabilities. There’s also some things that are objectively terrible about C, like undefined behavior. C compilers do their best to do the right thing with cursed code like i++ + i++; or a[i] = i++;. But that’s almost certainly not going to do what you want it to, and even worse, it may sometimes do the right thing.

Rust seems to be gaining popularity. There are some ambitious projects out there, like rewriting coreutils in Rust. Many other standard applications are getting a Rust rewrite. It’s fairly inevitable that the collection of Rust developers started to ask, could we invade the kernel next? This was pitched for a Linux Plumbers Conference, and the mailing list response was cautiously optimistic. If Rust could be added without breaking things, and without losing the very things that makes Rust useful, then yes it would be interesting. Continue reading “Things Are Getting Rusty In Kernel Land”

The Q2, A PDP8-Like Discrete Transistor Computer

[Joe Wingbermuehle] has an interest in computers-of-old, and some past experience of building computers on perfboard from discrete transistors, so this next project, Q2, is a complete implementation of a PDP8-like microcomputer on a single PCB. Like the DEC PDP-8, this is a 12-bit machine, but instead of the diode-transistor logic of the DEC, the substantially smaller Q2 uses a simple NMOS approach. Also, the DEC has core memory, but the Q2 resorts to a pair of SRAM ICs, simply because who wants to make repetitive memory structures with discrete 2N7002 transistors anyway?

SMT components for easy machine placement

Like the PDP-8, this machine uses a bit-serial ALU, which allows the circuit to be much smaller than the more usual ALU structure, at the expense of needing a clock cycle per bit per operation, i.e. a single ALU operation will take 12 clock cycles. For this machine, the instruction cycle time is either 8 or 32 clocks anyway, and at a maximum speed of 80 kHz it’s not exactly fast (and significantly slower than a PDP-8) but it is very small. Small, and perfectly formed.

The machine is constructed from 1094 transistors, with logic in an NMOS configuration, using 10 K pullup resistors. This is not a fast way to build a circuit, but it is very compact. By looking at the logic fanout, [Joe] spotted areas with large fanouts, and reduced the pull-up resistors from 10 K to 1 K. This was done in order to keep the propagation delay within bounds for the cycle time without excessive power usage. Supply current was kept to below 500 mA, allowing the board to be powered from a USB connector. Smart!

Memory is courtesy of two battery-backed 6264 SRAMs, with the four 12-bit general purpose registers built from discrete transistors. An LCD screen on board is a nice touch, augmenting the ‘front panel’ switches used for program entry and user input. A 40-pin header was added, for programming via a Raspberry Pi in case the front panel programming switches are proving a bit tedious and error prone.

Discrete transistor D-type flip flop with indicator. Latest circuit switched to 2N7002 NMOS.

In terms of the project write-up, there is plenty to see, with a Verilog model available, a custom programming language [Joe] calls Q2L, complete with a compiler and assembler (written in Rust!) even an online Q2 simulator! Lots of cool demos, like snake. Game of Life and even Pong, add some really lovely touches. Great stuff!

We’ve featured many similar projects over the years; here’s a nice one, a really small 4-bit one, and a really big one.


Apollo Guidance Computer Gets The Rust Treatment

Seems like all the cool kids are rewriting legacy C programs in Rust these days, so we suppose it was only a matter of time before somebody decided to combine the memory-safe language with some of the most historically significant software ever written by way of a new Apollo Guidance Computer (AGC) emulator. Written by [Felipe], the Apache/MIT licensed emulator can run either ROM files made from the computer’s original rope core memory, or your own code written in AGC4 assembly language.

It’s worth noting that the emulator, called ragc, needs a bit of help before it can deliver that authentic Moon landing experience. Specifically, the code only emulates the AGC itself and stops short of recreating the iconic display and keyboard (DSKY) module. To interact with the programs running on the virtual AGC you’ll need to also install yaDSKY2, an open source project that graphically recreates the panel Apollo astronauts actually used to enter commands and get data from the computer.

Of course, the next step would be to hack in support for talking to one of the physical recreations of the DSKY that have graced these pages over the years. Given the limitations of the AGC, we’d stop short of calling such an arrangement useful, but it would certainly make for a great conversation starter at the hackerspace.

Thanks for the tip, [CJ].

Blink An LED On A PIC32 With Rust, Easily

Got a PIC32 microcontroller and a healthy curiousity about the Rust programming language and its low-level capabilities, but unsure how to squash the two of them together with a minimum of hassle? If that’s the case, then today is your lucky day!

[Harry Gill] has you covered with his primer on programming a PIC32 with Rust, which will have you blinking an LED in no time. [Harry] admits that when he got started, his microcontroller programming skills were a bit rusty, so don’t let yourself think setting this up is beyond your abilities. If you have a working knowledge of the basics of microcontroller programming, you’ll be fine. [Harry] had to jump through a few hoops to get the right tools working, but thoughtfully documented the necessary steps, and provides a bare minimum hardware list.

Unsure what Rust is or what it offers? Check out the basics here, and see if it’s something that interests you. If you want to look even deeper, check out the kind of work that goes into writing a bare metal kernel in Rust.

Potassium ferrioxalate crystal

Growing Spectacular Gem-Like Crystals From Rust And Simple Ingredients

When we talk about crystals around here, we’re generally talking about the quartz variety used to make oscillators more stable, or perhaps ruby crystals used to make a laser. We hardly ever talk about homegrown crystals, though, and that’s a shame once you see how easy it is to make beautiful crystals from scratch.

We’ve got to say that we’re impressed by the size and aesthetics of the potassium ferrioxalate crystals [Chase Lean] makes with this recipe, and Zelda fans will no doubt appreciate their resemblance to green rupees. The process starts with rust, or ferric oxide, which can either be purchased or made. [Chase] chose to make his rust by soaking steel wool in a solution of saltwater and peroxide and heating the resulting sludge. A small amount of ferric oxide is added to a solution of oxalic acid, a commonly used cleaning and bleaching agent. Once the rust is dissolved, potassium carbonate is slowly added to the solution, turning it a bright green.

The rest of the process happens more or less naturally, as crystals begin to form in the saturated solution. And boy, did they grow — long, prismatic lime-green crystals, with a beautiful clarity and crisp edges and facets. The crystals don’t last long under light, though — they quickly lose their clarity and become a more opaque green.

[Chase]’s crystal-growing efforts have shown up here before, when he turned humble table salt into beautiful cubic crystals. We find the whole crystal-growing process fascinating, and we’re looking forward to more of this in the future.

The ray tracer racer

Whipping Together A Little Ray Tracer Racer

When you hear raytracing, you might think of complex dark algorithms that to stare too long at their source code invites the beginning of madness. And you’re technically not far off from the truth, but [h3r2tic] put a small open-source ray tracing game demo up on GitHub. The actual rust code powering the game is relatively short (just four files), with the longest file being the physics file. But, of course, there is a small mountain of code under this sample in the form of libraries.

Kajiya, physx-rs, and dolly are the three libraries that make this little demo possible. Kajiya, in particular, is what makes raytracing possible as it uses the newer RTX features (so only more recent Nvidia and AMD cards are supported) and Vulkan bindings. But, of course, it isn’t wholly ray-traced as we are still several years out from proper real-time raytracing. Nevertheless, the blend between raytracing and traditional rasterization looks incredible. The most important thing about this simple tiny sample isn’t the game itself but what it stands for. It shows how easy it is to create a sample like this. Even just five years, creating a demo like this required massive effort and expertise.

Visually, it is stunning to look at. While the reflections are most apparent, the takeaway from this is the ease that real-time global illumination brings. A quick look through the code shows that there are very few lights in the scene, despite looking well lit with soft shadows. Traditional video games spend a significant amount of development time lighting a scene, placing additional lights, and tweaking them to make up for all the shortcuts that lighting has to take in a rasterized environment. As more and more games are built with raytracing in mind rather than tacked on at the end, we can ditch the small crumbling mountain of hacks that we are forced to use in games today and just rely on the rays to accurately light a scene.

If using a library for your raytracing seems too easy, perhaps you’d like to take on the challenge of raytracing in excel. Video after the break.

Continue reading “Whipping Together A Little Ray Tracer Racer”

Making Your Own Touchpad With PWM And Rust

The modern touchpads are incredible feats of engineering, with everything from complex signal processing for noise and tremendous economies of scale driving prices low. So [Kevin] decided to see if he could make his own touchpad. Partially out of curiosity of what makes one touchpad better than another, but also because he was curious if he could. Using an STM32 and a custom PCB, he was off to the races in an incredibly cost-effective way.

After writing some quick firmware in Rust, he was reporting the values read by the PWM channels. Using python, he could get a good idea of the raw values that were being written over USB and visualized. So rather than implement filtering in hardware or firmware, he elected to do the filtering and processing on the host computer side in Python. We suspect this gave him much shorter iteration cycles.

If you like the idea of making your own touchpad but perhaps are dreaming a little bigger, why not make a tablecloth-sized touchpad?