| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
While usually `ioctl()` passes a pointer, the function call has been
overloaded to allow integers to be passed. For some platforms this
is an `int` and on others it's a `ulong`.
Fixes #824.
|
|
ioctls on FreeBSD and DragonflyBSD have a separate request code generation
macro `_IOWINT` which is now exposed as `request_code_write_int`.
`ioctl_write_int` is also fixed on these platforms to use this new request
|
|
* Split `ioctl!` into separate macros. This makes documentation easier to read.
* For every `ioctl_*!` macro include a description of the macro arguments as, the
function prototype for the generated wrapper function, and an example if we have one.
* Expose `request_code_*!` in the documentation to make the `ioctl_*_bad` macros easier to use.
* Reorganize the file hierarchy to be simpler
|
|
|
|
|
|
cc #664 (unsure if this is everything needed)
|
|
|
|
Instead of relying on the macro user to calculate the length in bytes
do that within the macro itself
|
|
|
|
There two different write semantics used with ioctls: one involves
passing a pointer the other involves passing an int. Previously the
ioctl! macro did not distinguish between these cases and left it up
to the user to set the proper datatype. This previous version was
not type safe and prone to errors. The solution here is to split the
"write" variant into a "write_ptr" and "write_int" variant that makes
the semantics more explicit and improves type safety by specifying
arguments better.
|
|
|
|
|
|
This also means that we need to properly mask off bits to the valid range
of ioctl numbers.
|
|
These are low-level functions that shouldn't be exposed
|
|
This refactors the examples to more directly address the exact use cases
for the `ioctl!` macro that `nix` provides. Additionally other macros
that should not be used by end users are no longer discussed.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
The test_ioctl values are computed using ioctl-test.c
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Consumers of the API may control visibility by means of a module. The
following is a useful pattern that may be used by implementors (here for
a couple of i2cdev ioctl definitions):
mod ioctl {
ioctl!(bad set_i2c_slave_address with super::I2C_SLAVE);
ioctl!(bad i2c_smbus with super::I2C_SMBUS);
}
This resolves #184.
|
|
Readability was unecessarily impaired via a myriad of attributes to
hide constants from the documentation. If these attributes are exposed
publically, including them in the documentation makes sense.
|
|
These had ior! rather than iow! previously. ior! is obviously
not correct for write operations.
|
|
if code incorporating these macros wants to publicly export the
functions they may do so by doing the following:
pub ioctl!(...);
Since the functions are unsafe, in many cases exposing the functions
publicly will not be desirable.
|
|
|
|
This change also adds macro usages in the tests. Nothing is asserted
but the use of the macros provides a basic compile-time check that
is otherwise missing.
Signed-off-by: Paul Osborne <osbpau@gmail.com>
|
|
This PR fixes the issue upstream https://github.com/rust-lang/rust/pull/26809
but no version 0.2.0 of the crate has been published as of yet.
Signed-off-by: Paul Osborne <osbpau@gmail.com>
|
|
|
|
|
|
|
|
This is more type-safe. Also, the old code wasn't cross-platform at all even
though it claimed to be. It wasn't even portable across architectures on
Linux.
|
