| Age | Commit message (Collapse) | Author |
|---|
|
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
|
|
|
|
Looks like a copy/paste error might have caused this
|
|
|
|
cc #664 (unsure if this is everything needed)
|
|
These are assumed to be QEMU issues, as they also fail on mips.
|
|
|
|
|
|
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.
|
|
|
|
|
|
The test_ioctl values are computed using ioctl-test.c
|
|
|
|
|
|
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 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
|
