[PATCH wayland] server: add helper functions for wl_global

Pekka Paalanen ppaalanen at gmail.com
Mon Mar 9 00:49:19 PDT 2015


On Mon, 23 Feb 2015 17:20:37 -0800
Bryce Harrington <bryce at osg.samsung.com> wrote:

> On Mon, Feb 23, 2015 at 11:30:57AM -0800, Bill Spitzak wrote:
> > Which of the 4 arguments do you use for your use case?
> > 
> > Because this can only return the first match I suspect some of the
> > NULL tests are pretty useless, because you have to specify arguments
> > that you know will return the one and only instance you are
> > interested in. It might be better to make this exactly match the use
> > case you have. If you are passing NULL just remove that argument,
> > and conversely remove the null test from this code for the arguments
> > you send. Basically don't add code that is not certain to be useful.
> 
> I would assume he's using all of them.
> 
> Regardless, so long as the test case covers an adequate number of
> permutations I don't see an issue with providing a generalized solution
> to this need.
> 
> However, I suspect this API would be better named as
> wl_global_find_first().
> 
> A more general wl_global_find() I would expect to be returning a list of
> results.
> 
> One thing to think about when writing a test case, is if this function
> will always return the same first result.  E.g. if the globals list
> depends at all on timing of hardware bringup thight might vary boot to
> boot, or if hashes are in any way involved in creating it, or etc.
> I'm guessing that's not the case, but probably worth checking, else
> we'll inevitably have a bug reported about it on some obscure piece of
> hardware.

Hi,

I'm certainly in favour of making this "find" API to return *all*
matches, not just a random match like it is now. Then, if the caller
expects to ever find either 0 or 1 globals, it can yell if that
invariant is ever broken.

But, I also cannot really see why the underlying problem could not be
solved completely inside the libEGL implementation.

If one is looking for an existing wl_drm global, you already assume it
has been created by *this* particular libEGL where you are currently
executing. Therefore, this loaded libEGL.so could maintain
library-global state where it lists the wl_drm globals it has created
and for which wl_display.

But, I also imagine that might be more complicated to realize than
using a find-API, so the idea of the find API is ok by me.

I would just want it to return all hits. That way you don't even need
to special-case the no-parameters case and you just trivially return
all globals.

Btw. just to be annoying... ;-)
Does EGL spec say anything about multi-threaded calls into the EGL API?
How do you know which lock protects the libEGL's globals? Is there only
one global lock for everything that would guarantee the list returned
by the find-API won't become out-of-date?


Thanks,
pq


> > On 02/23/2015 10:06 AM, Jonny Lamb wrote:
> > 
> > >+/** Find a wl_global given search parameters
> > >+ *
> > >+ * \param display The display object
> > >+ * \param interface The interface to match, or NULL
> > >+ * \param version The version to match, or 0
> > >+ * \param data The user data to match, or NULL
> > >+ * \param bind The function used to bind the object, or NULL
> > >+ * \return The first wl_global which matches, or NULL
> > >+ *
> > >+ * The global list of a wl_display is not public so this function helps in
> > >+ * finding a specific wl_global based on the parameters. Parameters can be
> > >+ * missing for a broader search (NULL for interface, data, and bind, and 0 for
> > >+ * version) but at least one must be present or no result will be returned.
> > >+ *
> > >+ * \memberof wl_global
> > >+ */
> > >+WL_EXPORT struct wl_global *
> > >+wl_global_find(struct wl_display *display,
> > >+	const struct wl_interface *interface, uint32_t version,
> > >+	void *data, wl_global_bind_func_t bind)
> > _______________________________________________
> > wayland-devel mailing list
> > wayland-devel at lists.freedesktop.org
> > http://lists.freedesktop.org/mailman/listinfo/wayland-devel
> _______________________________________________
> wayland-devel mailing list
> wayland-devel at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/wayland-devel



More information about the wayland-devel mailing list