Question regarding Rm_client::unmap in Fiasco.OC

[jaeyong yoo]

Hello,

While I was browsing, I found that, in function
Rm_session_client::detach(), there is a part that looping over Rm_client
and unmap it:

        for (Rm_client *rc = _clients.first(); rc; rc =
rc->List<Rm_client>::Element::next()) {
                /*
                 * XXX Unmapping managed dataspaces on kernels, which take
a core-
                 *     local virtual address as unmap argument is not
supported yet.
                 *     This is the case for Fiasco, Pistachio, and NOVA. On
those
                 *     kernels, the unmap operation must be issued for each
leaf
                 *     dataspace the managed dataspace is composed of. For
kernels with
                 *     support for directed unmap (OKL4 or Codezero), unmap
can be
                 *     simply applied for the contiguous virtual address
region in the
                 *     client.
                 */
                if (!platform()->supports_direct_unmap()
                 && dsc->is_managed() && dsc->core_local_addr() == 0) {
                        PWRN("unmapping of managed dataspaces not yet
supported");
                        break;
                }
                rc->unmap(dsc->core_local_addr() + region->offset(),   //
<=== this part
                          region->base(), region->size());
        }


The implementation of Rm_client::unmap is the following:

        void Rm_client::unmap(addr_t core_local_base, addr_t virt_base,
size_t size)
        {
                // TODO unmap it only from target space
                unmap_local(core_local_base, size >> get_page_size_log2());
        }

In the above function, since it is not using any member variables of
Rm_client, when Rm_session_client::detach() calls multiple of
Rm_client::unmap it is just calling the same function of "unmap_local" with
the same parameters.
It results in calling l4_task_unmap multiple times with the same parameters.
I'm just concern that this may not cause anything harmful.

Best,
Jaeyong
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.genode.org/pipermail/users/attachments/20121228/9c33441e/attachment.html>