Expose the raw module with a feature or move raw code to a different crate

[flaviojs]

I'd like some way to access the code in the raw module.
Anything works for me, #96 already mentions the possibility of using a feature or moving raw code to a different crate.

Rationale:
I'm converting code from C to rust bit by bit. There is lots of code, in the current stage I'm trying to stay as close to the unsafe original as possible to avoid introducing new bugs. At a later stage I'll be converting unsafe code to safe code.

Right now I'm working on code that uses libpcap.
I want to use this crate later, so to avoid incompatibilities I should use stuff from the raw module.

[Stargateur]

I advice you to fork temporary and expose this just for you so you can do as you want. And later switch to rust-pcap of crates.io directly.

[flaviojs]

Nope, not a good idea in terms of (temporary) maintenance. For now I'm just copy-pasting what I need.

If this crate wants to be a rust replacement for using libpcap then it should facilitate the transition from C/C++ to rust.
I don't mind doing the actual programming work, but the decision of where the crate wants to go should belong to the repo owners/maintainers.

[Wojtek242]

Would it not work to have your own "raw" module which you define yourself? The raw module was never exposed and based on other issues people have raised it seems to be possible to port C/C++ programs to Rust without it being exposed.

[flaviojs]

That is the copy-paste strategy... which means I would not get any of the updates this crate might do in raw, and I definitely want those updates. If raw was a separate crate that this crate depended on I would use that.

[Wojtek242]

Well, whether or not raw gets updates should not matter to a user of this crate. All functionality is exposed through Rust-native abstractions and no matter how many updates raw gets, the user API does not change. So if you were to start with a copy-pasted raw of today and your code worked today you could then slowly chip away at porting to this library even if this library's raw was being updated at the same time.

Furthermore, raw doesn't really get updates anyway. It's just a file with FFI bindings to libpcap. The only updates it gets is usually to uncomment some binding that we had commented before. Which also brings me to the point that if you use functionality that we currently that this library does not provide and that we have commented out in raw you'd be out of luck with our raw module. You'd have to maintain a delta yourself anyway.