Bikeshed: Should (Embedded) Linux Be Able to Implement These Traits?

[posborne]

In looking to address comments like some of those raised on the i2cdev crate (rust-embedded/rust-i2cdev#27 / rust-embedded/rust-i2cdev#28) I went around to the embedded RFCs and found time to review some of this for the first time.

The basic question here is whether it should be a goal or whether (and how) a concerted effort should be made to support the embedded-hal traits under Linux for usage/testing from a Linux userspace system such as a raspberry pi.

Benefits of Supporting Linux:

• Vastly increased hardware support. Once a trait is implemented for Linux, the support is available on a huge number of embedded devices, common ones being boards like the Raspberry Pi, Beaglebone Black, CHIP board, ...
• Easier test environment for device drivers. If I am adding support for some device, I might like to do more of that development in a less-embedded environment for easier debugging. If the traits are supported under Linux that fits the bill. Everyone has a RPi and can wire up a few peripherals quickly.

Challenges to Supporting LInux:

• Many of the Linux APIs are blocking but the embedded-hal APIs are non-blocking.

Life without Linux Support:

The dream is to be able to write a piece of higher-level code using a set of base APIs/Traits to access hardware and be able to have this code work in a variety of platforms, including Linux. If we end up needing a separate set of traits for systems like MCUs and systems like Linux then driver work for a particular sensor cannot be easily shared (there may still be opportunity for reuse in a crate but it would be additional work for the author).

I have not dug deeply into what it would look like to attempt to implement any of the existing or proposed traits for Linux but it would be an interesting thing to explore as the support would, in my opinion, be extremely nice.

All of this being said, I wholeheartedly believe that what is proposed here is the right approach when working with the actual hardware in a least-common-denominator system like an MCU.

[japaric]

The short answer is: yes.

The long answer is: but probably not the lowest level traits because they are tailored for MCUs where non-blocking operations are retry-able without having to track state in the program (the state is in the registers). That form of non-blocking operation is covered by the nb crate and the block!, try_nb! macros.

More concretely apart from the low level traits which are already in tree we want to add traits tailored for blocking operation and another set of traits for interoperation with futures. Where possible we want those traits to built on top of the existing low level traits to avoid rewriting register manipulation code in the implementation of the higher level traits.

I was originally envisioning something like this:

// write half the Serial trait we already have
trait Write<Word> {
    type Error;

    fn write(&self, word: Word) -> nb::Result<(), Self::Error>;
}

// Blocking write operations
trait BWrite {
    type Error;

    fn bwrite_all(&self, buffer: &[u8]) -> Result<(), Self::Error>;
    // ..
}

// overridable blanket implementation
default impl<S> BWrite for S where S: Write<u8> {
    type Error = S::Error;

    fn write_all(&self, buffer: &[u8]) -> Result<(), S::Error> {
        for byte in buffer {
            block!(self.write(*byte))?;
        }
        Ok(())
    }
}

However the default impl doesn't work today because of limitations of the feature (it doesn't work when associated types are involved) which throws a wrench into my plans. However, I think I have come up with a reasonable workaround. I'll test it and send a PR to show the approach.

[japaric]

Closing as this now exists in the form of the linux-embedded-hal crate.