Accessing devman devices using devmap handles does not work

[Jakub Jermář]

In devman_connection(), there is the following comment:

/*
 * Silly hack to enable the device manager to register as a driver by
 * the device mapper. If the ipc method is not IPC_M_CONNECT_ME_TO, this
 * is not the forwarded connection from naming service, so it must be a
 * connection from the devmapper which thinks this is a devmapper-style
 * driver. So pretend this is a devmapper-style driver. (This does not
 * work for device with handle == IPC_M_CONNECT_ME_TO, because devmapper
 * passes device handle to the driver as an ipc method.)
 */

Sounds scary, but in reality this does not work anyway. Trying to
connect to a devman-style driver (e.g. the serial driver) using its
devfs name will result in ENOENT being returned further down in the
function in the default alternative of the switch statement.

In other words, the method will be IPC_M_CONNECT_ME_TO no matter whether
the connection is opened using devman interfaces or devmap interfaces.

The reason is that devmap will forward its own IPC_M_CONNECT_ME_TO call
to devman like this:

ipc_forward_fast(callid, dev->driver->phone, dev->handle,
    IPC_GET_ARG3(*call), 0, IPC_FF_NONE);

dev→handle here is passed as the formal parameter named "method" but
because IPC_M_CONNECT_ME_TO is a system method, sys_ipc_forward_common()
will simply use it to replace ARG1 instead of the call's own method -
contrary to the comment.

The message when delivered to devman_connection() will be:

method = IPC_M_CONNECT_ME_TO
arg1 = dev->handle (devmap handle)
arg2 = flags

[Vojtech Horky]

I tried to bypass/fix this problem and in ​lp:~vojtech-horky/helenos/ddf-fixes branch is my proposal.

The trick is quite simple – when registering new device within devmapper, it is possible to (optionally) pass extra parameter associated with the device. When this parameter (called forwarding interface) is non-zero, devmap passes it as the first parameter (and device handle as the second) when forwarding calls to the driver. When the interface is zero, old behavior is used and only handle is passed.

The naming of the extra parameter seems stupid to me but I was not able to come up with anything better. Suggestions welcomed .

The hack could be described as a way of telling devmap: "Hey, my driver is accessible through various ways and I need to distinguish them. So, whenever you forward some connection to me, be so kind and tell me about it using this interface (identification).".

The original forwarding copied the value of third call argument but AFAIK that would be always zero, thus the new version does not copy it at all. Is that correct?

I abused the virtual devices/drivers under virtroot for creating simple /dev/null-style device for testing – see tester virtchar1.

[Vojtech Horky]

Merged into mainline:755.