bug-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

About consuming/releaseing ports in libpciaccess


From: Joan Lledó
Subject: About consuming/releaseing ports in libpciaccess
Date: Sun, 14 Nov 2021 12:17:20 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0

Hi,

I'm trying to implement a correct release of resources in libpciaccess x86 module. I have this text from Sergey as reference:

> Consuming, as in taking ownership of, or "eating" the passed-in reference.
>
> If a call consuming something, the callee takes ownership of the
> passed-in reference:
>
> some_resource_t global_resource;
>
> void
> callee (some_resource_t *argument)
> {
>    /* Take ownership.  */
>    global_resource = argument;
> }
>
> void
> caller ()
> {
>    some_resource_t *res = make_resource ();
>    callee (res);
> /* No need to release the resource -- the callee took ownership of it. */
> }
>
> If the call is *not* consuming something, the caller keeps ownership
> of the reference, and the callee has to add another reference if it
> wants to keep the resource for longer:
>
> some_resource_t global_resource;
>
> void
> callee (some_resource_t *argument)
> {
>    /* Add a reference since we're storing the resource for longer.  */
>    some_resource_ref (argument);
>    global_resource = argument;
> }
>
> void
> caller ()
> {
>    some_resource_t *res = make_resource ();
>    callee (res);
>    some_resource_rele (res);
> }
>
> For MIG routines, the convention is that the routine implementation
> takes ownership of all passed-in resources (except the request port)
> if and only if it returns KERN_SUCCESS (aka 0) or MIG_NO_REPLY. In
> other cases (so, for error returns) MIG runtime (or technically not
> even MIG but rather mach_msg_server ()) will destroy any resources in
> the message.

Please take a look at map_dev_mem() implementation in my branch at [1].

So, as I understood it, if the callee is supposed to take ownership of all given resources except the request port, then in the call to device_open(), the routine is not consuming the master_device and I should release it after the call, is that right?

a few lines below, it's the same situation when calling device_map(), it's not consuming devmem, so should I call device_close and release it after the call?

And what about the pager after calling vm_map? since it's not the request port I assume vm_map() takes ownership and I don't have to care

----
[1] https://gitlab.freedesktop.org/jlledom/libpciaccess/-/blob/hurd-device-map/src/x86_pci.c#L244



reply via email to

[Prev in Thread] Current Thread [Next in Thread]