Open koutheir opened 2 years ago
I made the PR but I didn’t try it: https://github.com/sanpii/lxc-rs/pull/14
It’s work fine:
Container state: RUNNING
Container PID: 32254
Interfaces: ["eth0", "lo"]
IPs: [10.0.3.206]
The only issue remaining is the unwrap()
calls that panic if liblxc
generates an error. This is not reasonable for a library.
The only issue remaining is the
unwrap()
calls that panic ifliblxc
generates an error. This is not reasonable for a library.
There is many unwrap
in my code, I work on a redesign of errors handling.
Until panics are reduced to a minimum, the only crate I can currently use is lxc-sys
, basically reimplementing the ergonomic structures while reporting liblxc
errors as normal Result
s.
@koutheir The PR is here: https://github.com/sanpii/lxc-rs/pull/16
The
lxc::Container::get_ips()
API encapsulates theget_ips()
oflxc_sys::lxc_container
.There are multiples issues with the design of
lxc::Container::get_ips()
:Vec<String>
instead ofVec<std::net::IpAddr>
. IP addresses are rarely used simply as strings. They're often parsed before becoming useful.interfaces: &str
:get_ips()
gets aninterface: *const c_char
. Using the plural form "interfaces" is misleading.get_ips()
can acceptNULL
as the value for this parameter, which has its own semantics in the implementation ofget_ips()
inliblxc
.family: &str
: the rawget_ips()
can acceptNULL
as the value for this parameter, which has its own semantics in the implementation ofget_ips()
inliblxc
.scope: i32
, but the rawget_ips()
gets ascope: c_int
. Assuming that a Cint
maps always toi32
is a bad idea, and is not always true.Given all these points, I suggest changing the prototype of
lxc::Container::get_ips()
to the following: