Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Ubus (OpenWrt micro bus architecture)

openwrt.org

Post reply on HN
Print view View original

51–56 of 56 posts

Re: Ubus (OpenWrt micro bus architecture)

#51

Post by IOT_Apprentice »

lionkor wrote: post #10
fulafel wrote: post #2

Did they consider using a memory-safe language for this?

There is no real case to be made against the idea of memory safety, but there is a case to be made for C. You can write C code such that its unit tested, fuzzed, statically analyzed and reviewed, and often embedded code has one or two specific jobs. I would have loved to see Zig here, as it makes all of the above (testing, analysis, code clarity for review) easier, but its also not memory safe necessarily. You could…

They just rewrite the impacted mess in Rust?

Re: Ubus (OpenWrt micro bus architecture)

#52

Post by westurner »

packetlost wrote: post #48
westurner wrote: post #45

Earlier quoted context omitted.

But then when I need to scale to more than one node with multiple cores, do pipes scale?

Yes, with some work: https://mazzo.li/posts/fast-pipes.html

https://mazzo.li/posts/fast-pipes.html#splicing :

> In general when we write to a socket, or a file, or in our case a pipe, we’re first writing to a buffer somewhere in the kernel, and then let the kernel do its work. In the case of pipes, the pipe is a series of buffers in the kernel. All this copying is undesirable if we’re in the business of performance.

> Luckily, Linux includes system calls to speed things up when we want to move data to and from pipes, without copying. Specifically:

> - splice moves data from a pipe to a file descriptor, and vice-versa.

> - vmsplice moves data from user memory into a pipe.

> Crucially, both operations work without copying anything.

But then to scale to more than one node, everything has to be copied from the pipe buffer to the network socket buffer; unless splice()'ing from a pipe to a socket is Zero-copy like sendfile() (which doesn't work with pipes IIRC).

"SOCKMAP - TCP splicing of the future" (2019) https://blog.cloudflare.com/sockmap-tcp-splicing-of-the-futu...

Re: Ubus (OpenWrt micro bus architecture)

#53

Post by packetlost »

westurner wrote: post #52
packetlost wrote: post #48

Earlier quoted context omitted.

Yes, with some work: https://mazzo.li/posts/fast-pipes.html

https://mazzo.li/posts/fast-pipes.html#splicing : > In general when we write to a socket, or a file, or in our case a pipe, we’re first writing to a buffer somewhere in the kernel, and then let the kernel do its work. In the case of pipes, the pipe is a series of buffers in the kernel. All this copying is undesirable if we’re in the business of performance. > Luckily, Linux includes system calls to speed things up wh…

sendfile is implemented with splice, but the scenario in which splice is actually zero-copy is not well defined (man pages just say "it's generally avoided"), so you'd have to dig into your kernel source to know for sure. That being said, chances are the cost of copying the data would be far outpaced by the cost of serializing over the network anyways, so you would want to architect your application in a way that you're sending as little data over the network as possible if performance is of maximum concern.

Re: Ubus (OpenWrt micro bus architecture)

#54

Post by westurner »

packetlost wrote: post #53
westurner wrote: post #52

Earlier quoted context omitted.

https://mazzo.li/posts/fast-pipes.html#splicing : > In general when we write to a socket, or a file, or in our case a pipe, we’re first writing to a buffer somewhere in the kernel, and then let the kernel do its work. In the case of pipes, the pipe is a series of buffers in the kernel. All this copying is undesirable if we’re in the business of performance. > Luckily, Linux includes system calls to speed things up wh…

sendfile is implemented with splice, but the scenario in which splice is actually zero-copy is not well defined (man pages just say "it's generally avoided"), so you'd have to dig into your kernel source to know for sure. That being said, chances are the cost of copying the data would be far outpaced by the cost of serializing over the network anyways , so you would want to architect your application in a way that yo…

I haven't checked, but by the end of the day, I doubt eBPF is much slower than select() on a pipe()?

Re: Ubus (OpenWrt micro bus architecture)

#55

Post by tmzt »

mkj wrote: post #30
no_time wrote: post #29

Earlier quoted context omitted.

>I'm hopeful. no_std rust binaries can be near competitive with C. I feel like Rust without std might as well be a different language. Almost all of the available mindshare, docs, libraries are dependant on it. Sure, you can use it. But to me it just looks like technological poverty. Even compared to the C ecosystem.

I'd disagree. Using something like Embassy is pretty pleasant for embedded development, less worries than C. The only issue is maturity. There were sufficient crates to write a ssh server for a rp2040 (mostly out of curiosity) using what's available in no_std.

Do you have that example posted anywhere? I'm curious to see it. Also, any support for the Wifi and/or Bluetooth on Pi Pico W from Rust?

Re: Ubus (OpenWrt micro bus architecture)

#56

Post by mkj »

tmzt wrote: post #55
mkj wrote: post #30

Earlier quoted context omitted.

I'd disagree. Using something like Embassy is pretty pleasant for embedded development, less worries than C. The only issue is maturity. There were sufficient crates to write a ssh server for a rp2040 (mostly out of curiosity) using what's available in no_std.

Do you have that example posted anywhere? I'm curious to see it. Also, any support for the Wifi and/or Bluetooth on Pi Pico W from Rust?

https://github.com/mkj/sunset/tree/main/embassy/demos/picow is a wifi-ssh to serial impl for a rp2040. I've got it plugged into my home server's serial port. It's using cyw43 for wifi also from Embassy - dirbaio is prolific! There's some WIP in Embassy for bluetooth.

That repo has a few crates depending on each other - sunset is the toplevel ssh, sunset-embassy adds no_std async, then the async dir has std rust, with a commandline ssh client in the examples dir.

Post reply on HN