Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Factor out the "raw_socket" and "tap_interface" features #15

Merged
merged 2 commits into from
Jun 15, 2017
Merged

Factor out the "raw_socket" and "tap_interface" features #15

merged 2 commits into from
Jun 15, 2017
+32 −18

Conversation

batonius
Copy link
Contributor

Problem: I'm investigating the possibility of using smoltcp in Redox (yeah, I know, I'm not the first one). The unusual thing about Redox is that while it has a version of Rust's libstd, it doesn't have libc and the libc crate doesn't support it, so while it's possible to use std::Box and std::Vect, raw sockets are unavailable. As a result, it's impossible to build smoltcp for Redox with the std feature on, which leaves many features disabled for no reason.

Solution: The PR factors out the raw_socket and tap_interfaces features, making the std feature not dependent on the libc crate. raw_socket and tap_interfaces are still default features. With this PR it's possible to build smoltcp for Redox with --no-default-features --features="collections alloc std".

Other: I was going to create a long-term fork, but turns out the required changes are minimal, so if it's ok with you, it would be great to depend directly on the original.

@batonius
Factor out the "raw_socket" and "tap_interface" features.
550cd86 
This makes possible building smoltcp with the "std" feature on paltforms without libc.
@whitequark
Copy link
Contributor

whitequark commented Jun 15, 2017 •
edited
Loading

The Travis build has failed. It looks like the build matrix got out of sync with the feature set.

@batonius
Copy link
Contributor Author

Fixed.

@whitequark whitequark merged commit 80c20ad into smoltcp-rs:master Jun 15, 2017
@whitequark
Copy link
Contributor

I was going to create a long-term fork, but turns out the required changes are minimal, so if it's ok with you, it would be great to depend directly on the original.

Oh and any chances needed for redox (e.g. a DHCP packet parser/serializer, as discussed in the other PR) are rather welcome in smoltcp. I would prefer to not have redox #[cfg]s because it indicates some unsolved underlying problem but otherwise it's fine.

@batonius batonius deleted the split_std branch June 15, 2017 10:16
@batonius
Copy link
Contributor Author

Good to know.

By the way, how do you feel about raw sockets? We need them for ping, obviously, but I was also thinking about using them to migrate the existing network stack piecemeal, i.e. to provide level 3 abstraction to the existing tcpd, udpd and icmpd daemons at first. This means raw sockets should have a priority over the build-in handlers, which looks like the standard behavior, http://man7.org/linux/man-pages/man7/raw.7.html :

When a packet is received, it is passed to any raw sockets which have been bound to its protocol before it is passed to other protocol handlers (e.g., kernel protocol modules).

It looks like a pretty straightforward thing to do, being similar to UDP. So, if I add them, will you consider merging?

@whitequark
Copy link
Contributor

Naturally.

@whitequark
Copy link
Contributor

Oh regarding ping, I would rather like to have an ICMP socket option, the equivalent of socket(PF_INET, SOCK_DGRAM, IPPROTO_ICMP); on Linux.

@batonius
Copy link
Contributor Author

Interesting, I didn't know SOCK_DGRAM+IPPROTO_ICMP is a thing, I guess I'll look into adding ICMP sockets as well.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

None yet
2 participants
@batonius @whitequark