Support #![no_std]

[carlpaten]

A lot of people are writing operating systems kernels in Rust, and they'll be looking for a network stack. pnet could be a choice option.

Some thoughts:

• nom implements this as a feature on their package. Compiling with the core feature means that #![no_std] compilation is supported.
• It's probably reasonable to assume support for core, alloc, and collections.
• On the other hand, assuming support for libc is not going to go well. AFAIK It's pretty much an interface to glibc, which I wouldn't expect anyone to port to their OS.

[mrmonday]

I definitely would like to see support for libpnet in the Rust-based OSes - unfortunately it's not as simply as supporting #![no_std] though. Some thoughts on the matter:

• All the datalink backends are operating system specific, so by implementing a backend for , you could support #![no_std] for it, depending on how it's implemented. Right now all backends require libstd, since it is available on all supported OSes. I guess the exception could be if you're attempting to target an embedded Linux - I'd love to hear more from someone working on that so we can see what libpnet can do for that environment.
• The transport-level stuff requires a posix-like API from the OS - it's likely easiest to just disable this completely when targetting new OSes.
• pnet_macros does rely somewhat on std, and so, transitively, so does libpnet - it should be fairly simple to remove this dependency though.
• libpnet isn't a network stack - it could be (and hopefully will be!) used to build a network stack though. I'd love to see some of the OS guys build a network stack atop of libpnet for their OSes, it would mean we've got an instantly cross-platform network stack - one that works on both their OS, and on Windows/Linux/OS X/FreeBSD/Whatever else libpnet ends up supporting (and, maybe even other Rust OSes!). I'm envisaging something like what's implemented in the seastar framework or mTCP - we're in the great position of not having to support a legacy interface, so we can build in things like zero-copy from the start.

I'm happy to mentor anyone who wants to start building a network stack with libpnet, or who wants to get it working on their OS.

[little-dude]

it would mean we've got an instantly cross-platform network stack

that would be pretty awesome !

[carlpaten]

I'm happy to mentor anyone who wants to start building a network stack with libpnet, or who wants to get it working on their OS.

Well, hello there :)

We're developping a library operating system in Rust targetting the Xen hypervisor. If everything goes well we're going to be working in a network stack at some point in the January-April period. pnet caught my eye - it's written in Rust and seems well-built.

It's possible that we'll fork pnet and send back patches. At worst, we'll use pnet as a reference implementation for early work, and then report back with a discussion of what API changes we had to make to work in a freestanding environment. (We also might integrate with an off-the-shelf C or C++ solution, but our experience with going down that path has been absolutely horrible so far.)

[mrmonday]

There's definitely room for improvement in the libpnet API - I've had lots of ideas about changes I want to make, but not had sufficient time to implement them. I've been working on issue #1 recently (one of the biggest remaining limitations in libpnet's current API - that I know of), but haven't finished up my work on that yet.

You might be interested in taking a look at my paper about libpnet, it talks a little about some of the design, might be of interest when you come to actually implementing the network stack.

Patches and pull requests are always welcome - I look forward to seeing what you come up with. Good luck with your OS!

[carlpaten]

Thank you so much for that paper - I'm currently writing up a paper about our progress thus far and our future plans. This is going to be a choice reference :)

[mrmonday]

I hope it's useful to you!

Let me know if you have any questions, I'd be happy to answer them. It's fairly rough in places, there's definitely a sense of "last minute rush to get it done" at some points.

[tytouf]

As there been any progress/update on that issue?

[mrmonday]

None that I'm aware of.

As I mentioned earlier in the thread - there's not too much effort involved in getting this working, it just needs someone to do it. I'm happy to mentor this if you're interested.

[infosechoudini]

@carlpaten @tytouf

I just made a branch and started working on no_std support for this. I'm starting with the following which seem the most straightforward without building a brand new lib to implement kernel stuff.

In Scope

• pnet_macros
• pnet_macros_support
• pnet_base
• pnet_packet
• pnet_base

The following are out of scope due to the need to have a design conversation about using libc::af_packet and etc and the possible need to implement a rust version libc for linux and something to that affect for windows et. al. in order to enable these.

Out of Scope

• pnet_sys
• pnet_transport
• pnet_datalink

Reiterating @mrmonday comments above: #133 (comment)

Branch: https://github.com/infosechoudini/libpnet/tree/no_std

[Felix-El]

Hi, also offering to contribute my implementation of no_std for pnet.
(Rust beginner - thorough review appreciated.)

[Felix-El]

Great to see #562 merged, however also #566 needs to be merged to really get rid of the dependency on std.

[nc7s]

FYI there's dunmatt/no-std-net#16 and the repository owner is completely off the radar for the entire 2023. Maybe consider using a maintained crate for no_std networking.

[Felix-El]

Thanks @bnoctis,
The net address structures have become part of the core library recently, so no-std-net might be removed entirely.
Looks like this is the case from Rust 1.72.1 on (rust-lang/rust@6cb3449).
@mrmonday would it be an option to assume MSRV >= 1.72.1 ?

[faern]

core::net is now stable since Rust 1.77. So we do not need to depend on no-std-net at all if we accept 1.77 as MSRV. This would be great IMHO, since toggling between types is not ideal.