Adding no_std support

[SimonIT]

My goal is to add no_std support for use in Ariel OS.

[ZiggVert]

I'm really interested in this work! I'm also hoping to get wireguard running on a small embassy project.

We have tried using rustyguard but it appears, at least currently, to not be no_std compatible. Did you look at rustyguard before setting off on this work?

Would you consider switching to the embassy-sync mutex instead of bringing in yours from arial-os? Or is this something I could easily swap out myself?

[SimonIT]

We have tried using rustyguard but it appears, at least currently, to not be no_std compatible. Did you look at rustyguard before setting off on this work?

No, I haven't seen it. You mean this rustyguard? Also, the license isn't specified. I'm writing my bachelor's thesis on integrating WireGuard with Ariel OS, so I'm short on time.

Would you consider switching to the embassy-sync mutex instead of bringing in yours from arial-os? Or is this something I could easily swap out myself?

Yes, I wanted to do it with Embassy Sync. However, I didn't want to change the entire locking system, including the one used for desktop parking_lot, so I took the easiest route and implemented RawMutex for Lock. It's more difficult with Embassy Sync because there are no unlock and try_lock functions in the blocking_mutex.

Yes, it is easily swappable in this PR because the RawMutex is chosen via a compiler flag.

I created a driver, ariel-os-wireguard, which is essentially an embassy driver, but with the lock dependency tied to Ariel OS. There is an example that has yet to be tested.

I'm happy to change the lock to an embassy-only lock.

[ZiggVert]

This rustyguard which promises to be a no_std wireguard impl, but I think what you're doing with boringtun is a better approach - its more mature and has, in my opinion, an easier API.

Are you hoping that this branch will be merged at some point in the future? I notice that currently some of your changes (eg to embedded_time away from std::time) are not feature gated (unless I'm misreading). Do you plan to feature-gate all your changes behind the std feature?

Great work getting this working in any case. I'll start to experiment with this branch if I find time next week.

[SimonIT]

This rustyguard which promises to be a no_std wireguard impl, but I think what you're doing with boringtun is a better approach - its more mature and has, in my opinion, an easier API.

It might have been easier to do, but here we are.

Are you hoping that this branch will be merged at some point in the future? I notice that currently some of your changes (eg to embedded_time away from std::time) are not feature gated (unless I'm misreading). Do you plan to feature-gate all your changes behind the std feature?

Yes, I would like that. However, the change from std::time to embedded_time is breaking though it's needed. Otherwise, it wouldn't run in no_std.

Great work getting this working in any case. I'll start to experiment with this branch if I find time next week.

Thanks! I'm also trying to see if it works

[SimonIT]

I think I encountered issue #353 too, but I'm not 100% sure. The handshake initiation is sent, but the other peer doesn't respond. The handshake is only successful and data is sent if I trigger a handshake from the other peer with a ping, for example