As described in #117, the `AsExtStr` trait is defined to return a raw `*const
libc::c_char`. Its impl for `OsStr` simply borrowed the byte slice from its
`OsStr` argument and cast it to a `*const libc::c_char`, which does not
construct a proper null-terminated C string.
Given this, the `AsExtStr` is not necessary and is removed. `NixPath` is
updated to yield `CStr`.
Fixes#117, #120
Thanks to @dead10ck
Two problems were fixed:
1. All of the comments for the module were prefixed with `///!` instead
of just `//!`
2. There was no newline before lists which is required in markdown, so
they were not rendering correctly.
The ioctl interface expected by most external parties is that of
an unsigned long (c_ulong). The libc crate expects as an int. This
change exposes c_ulong (via ioctl_op_t) to external users and
casts to c_int before calling the libc function.
The only documentation in SUSv3 for ioctl has to do with stream
devices. The support documented there is not widely supported (it
is not supported by the Linux kernel)[1].
[1] The Linux Programming Interface, Page 86.
This commit provides a new implementation for ioctl that is much
more generic, allowing for clients to use send any manner of ioctl
requests at special files. The implementation provides two main features
that help to raise the level of abstraction over that provided by libc.
1. The module now provides functions that provide the same functionality
as the linux kernel _IO* macros. These are used frequently in the
linux kernel for building ops for ioctls. The use of these helper
functions are not required.
2. Functions are provided for the 3 main types of ioctl usage patterns
(read, write, and execute). For many subystems, the read() call
which returns a Result<T> and the write calls taking a &T provide
a nice interface.
All of the methods wrapping ioctl are unsafe and will probably need to
remain that way unless knowledge of the semantics of every possible
ioctl call are added to the nix library. The best that exists for
ioctls are some conventions around the op, but even these conventions
are really only used for newer devices added to the kernel.
This change resolves#108
The limit of 32 cores may not actually be a limit with arm-linux, but
I am not aware of anything in excess of 32 processors out there currently
and this is what I have been running for awhile now on a beaglebone
black (`--target=arm-unknown-linux-gnueabihf`).
This change addresses #95 and relates to #97.
Initially support this by assuming the lowest common denominator. The long
term solution is to improve the build system to allow pulling in more specific
features that are available on the target system.
