On 20/07/2016 13:03, Christoph Lameter wrote:
On Wed, 20 Jul 2016, Matan Barak wrote:
+struct ib_uverbs_ioctl_hdr {
+ __u16 length;
+ __u16 flags;
+ __u16 object_type;
+ __u16 driver_id;
driver id??? I would have expected that the driver to be used is
already selected through the file handle as passed to the ioctl.
If I recall, Jason proposed that. I think the main reason here is for strace
and debugging. Since the ABI is now driver specific, this helps you parse the
structs via strace.
You specify the driver_id in the ioctl data structure. The driver in an
ioctl is specified by the descriptor. strace etc would have an easier time
if we would follow the standard conventions for devices and not add
another device_id somewhere.
If you use only one file (ie rdma_uapi), how will strace know which
internal RDMA device is used?
It'll need to same some bits for the entire session to figure that out.
This is actually an ongoing discussion we have in the OFVWG. The benefit of
unifying rdma-cm and uverbs is that sharing objects (and opening a device
through rdma-cm and pass it to user-space) becomes easier. That means that
security should be handled via selinux.
Why would there be an issue of sharing data between multiple descriptors?
Data could be a subsystem specific state and not device specific if you
want to share.
Currently uverbs and rdma-cm IDRs are separated. If we would like to
introduce a semantics where rdma-cm opens the device (and maybe even
access the device's objects) it needs to somehow share ids with the
ib_dev context.
So do you suggest that rdma-cm will get a fd and open the required
device on this fd while returning a handle bounded to this fd (you still
need to bind the fd to its objects due to security reasons).
I guess we have a good reason for doing so? If so then please document
that somewhere. Or did I not see that?
The current v2 approach only adds the driver_id for information and strace
only. I would really like to hear your insights about using a single file
(rdma_uapi) vs multiple files as we have today.
Why do you need that information a second time if the descriptor already
provides the device information?
The simple approach would be to have either /dev or /sysfs based
descriptors that can be opened and then used for ioctls. F.e. open
/sys/class/infiniband/mlx5_0/desc or
/sys/class/infiniband/mlx5_0/ports/1/desc
or create a new hierachy using udev/systemd
f.e. /dev/rdma/mlx5_0
and then run ioctls on that file to configure the device. That is very
similar to the traditional use of ioctls. Security for each device can be
controlled separately without inspecting the data being passed (which
would require modifications to the security code). strace and
other tools would just natively know that the descriptor refers to a device.
Additional system calls would allow a straightforward war to control
passing the descriptor on exec and other fuunky things (see manpage
for fcntl f.e.). The usual machinery for device descriptor control and
management would come in almost for free.
That's exactly where we stand right now. There are some supporters for
unifying all devices to one file. Even if you want to unify rdma-cm to
the same fd and open the device through it, strace can't know which
physical device is used.
If we keep file per device as you described, we don't need this field.
IOCTL(2) Linux Programmer's
Manual IOCTL(2)
NAME
ioctl - control device
SYNOPSIS
#include <sys/ioctl.h>
int ioctl(int d, int request, ...);
DESCRIPTION
The ioctl() function manipulates the underlying device parameters
of special files. In particular, many operating charac‐
teristics of character special files (e.g., terminals) may be
controlled with ioctl() requests. The argument d must be an
open file descriptor.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
