Week 0003

Taking the whole week off from $dayjob. Since we are still in covid times this will be a staycation, but still very pleasant to have more time to relax.

Continuing to work on updating my resume. After last week's adventures in HTML → PDF conversion I decided to stick with the LaTeX format of my resume that I've been using for many years.

Upstreamed a small fix in Linux for the iMac12,1 backlight. It's only a couple lines of diff, but it feels nice to fix up some old (but not that old) hardware to benefit anyone still using it.

Experimenting with some kind of consistent buffer API in uefi-rs. A consistent pattern that comes up a lot is that UEFI has a function to read data into a buffer (often, but not always, a u8 slice), and if the buffer is not big enough it will return BUFFER_TOO_SMALL. In some cases we have manually wrapped such functions to provide a more convenient API that uses a Vec as the buffer so that we can resize it as needed until it's big enough. Since allocation is optional in uefi-rs, the latter interface is hidden behind the exts feature.

It would be nice if we had a way to do all that without the manual boilerplate. I'm experimenting with having a Buffer trait that can be backed by either an array or a Vec, and seeing how far I can get with that.

One area of uefi-rs that has consistently tripped me up is uefi::Result, which tries to cleanly separate errors from warnings (UEFI packs both of these into the EFI_STATUS enum.) I'm going to write up a proposal to simplify this type and see what people think.

RFC for removing uefi::Completion is now up: https://github.com/rust-osdev/uefi-rs/issues/360

Also put up a PR that implements the change. +179/−395 :)

ChromeOS Flex is now publicly announced! We worked very hard on it, please clap.

Some dicussion on the RFC for removing uefi::Completion. Plan is to give it some more time so that people have a chance to notice it and comment.

Spent a little time learning about OP-TEE in order to respond to a uefi-rs question. Seems like client applications wouldn't need to be directly supported in uefi-rs, but rather a separate complementary crate. Could be wrong though.

Put up a uefi-rs PR to remove some implicit string conversion. Also increased the test coverage a little bit.

Did some initial investigation into what it would take to get code coverage information out of uefi-test-runner. As the project gets bigger it would be helpful to have a better handle on what all is actually tested (or not). minicov looks promising, but I immediately ran into a rustc bug. Hopefully the associated PR will be merged soon and I'll give it another try then.