Consider using smoltcp

[whitequark]

I've been looking at the current state of the embedded ecosystem in Rust and stumbled upon this crate. It looks like (at least for now) it's duplicating the work I did for https://github.com/m-labs/smoltcp. Perhaps you could make use of that.

[phil-opp]

Thanks for the hint. We know about smoltcp and really like it overall. However, there are some API choices that we don't like:

• The transmit function of the Device can't return an object with the same lifetime as self. This makes it difficult to apply Rust's ownership mechanisms (e.g., the ethernet driver owns the transmit buffer and only returns a reference to it).
• We don't like the "send on drop" API, because it requires static functions and locks. Also, the send process is implicit and not visible in the code.
• We don't quite like the step-by-step wrapping and unwrapping required by the wire module. Instead, we would prefer a parse method that unwraps all layers at once and returns a type that allows pattern matching.

So we're trying an alternative API design in this crate. We tried to base it on smoltcp, but creating our own types was easier, at least for experimentation purposes. However, we might revisit this decision when we start to tackle more complicated protocols such as TCP :).

[whitequark]

The transmit function of the Device can't return an object with the same lifetime as self. This makes it difficult to apply Rust's ownership mechanisms (e.g., the ethernet driver owns the transmit buffer and only returns a reference to it).

We don't like the "send on drop" API, because it requires static functions and locks. Also, the send process is implicit and not visible in the code.

I'm not especially fond of these APIs either. The current state is the "least bad" one I could achieve but by no means it is the final one nor a good one. I would rather welcome suggestions in this area.

We don't quite like the step-by-step wrapping and unwrapping required by the wire module. Instead, we would prefer a parse method that unwraps all layers at once and returns a type that allows pattern matching.

Hm, surely you are aware that smoltcp has parse methods? They don't unwrap all layers primarily because that's never actually useful. The TCP machine is abstracted over the IP layer it uses, and the IP packets are currently only encapsulated in Ethernet, but in the future there will probably be PPP or SLIP.

[phil-opp]

I would rather welcome suggestions in this area.

In general, I would prefer a closure-based API, e.g.:

fn transmit<F>(&mut self, len: usize, f: F) -> Result<(), Error>
    where F: FnOnce(&mut Self::TxBuffer);

I'll try to make concrete suggestions when I have a more fleshed out design.

[whitequark]

In general, I would prefer a closure-based API, e.g.:

Obviously. This was the first iteration of my design. Unfortunately, this means that transmitting a packet requires copying out the relevant parts of the received packet. That was in conflict with some of my earliest design ideas, but, I think, not anymore.

Anyway, if you would like to see smoltcp go back to that design, please file a bug and I think I can just do that now.

[whitequark]

In general, I would prefer a closure-based API, e.g.:

fn transmit(&mut self, len: usize, f: F) -> Result<(), Error>
where F: FnOnce(&mut Self::TxBuffer);

I've recently revisited this. It's as simple as:

Unless you're willing to allocate a supplementary buffer that's as large as the largest packet that may be received (I don't think I am), you need simultaneous access to the read and write halves of the device.

[oli-obk]

In our case we need that buffer anyway, since the hardware reads into a buffer supplied to it. We can access this buffer while writing to the output to best of my knowledge.

[whitequark]

Not if you use a closure-based API that takes a &mut self you cannot.

[whitequark]

We don't like the "send on drop" API, because it requires static functions and locks. Also, the send process is implicit and not visible in the code.

JFYI I just refactored smoltcp so that the "send on drop" behavior can be cleanly removed. I have no immediate plans to do so but if you express interest I'll do that.

[whitequark]

The transmit function of the Device can't return an object with the same lifetime as self. This makes it difficult to apply Rust's ownership mechanisms (e.g., the ethernet driver owns the transmit buffer and only returns a reference to it).

Also, I think I can fix this too, but I'm slightly less certain about it.

[phil-opp]

@whitequark Thanks for the notice! From a quick look it looks much better now. I will take a closer look and reevaluate it for our project. Maybe it's possible to incorporate the ideas from our prototype now.