From: Thierry Reding <thierry.reding@gmail.com>
To: Emil Velikov <emil.l.velikov@gmail.com>
Cc: ML dri-devel <dri-devel@lists.freedesktop.org>
Subject: Re: [PATCH libdrm 2/3] tests/util: Make util_open() use drmDevice
Date: Wed, 1 Feb 2017 16:59:32 +0100 [thread overview]
Message-ID: <20170201155932.GA18725@ulmo.ba.sec> (raw)
In-Reply-To: <CACvgo53FhtecMLF4M8Z0dPgYvtm4px3qg_54WUVxGxk-ySwtRg@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 4195 bytes --]
On Wed, Feb 01, 2017 at 12:47:21PM +0000, Emil Velikov wrote:
> On 30 January 2017 at 10:29, Thierry Reding <thierry.reding@gmail.com> wrote:
> > From: Thierry Reding <treding@nvidia.com>
> >
> > The util_open() helper is used in a couple of test programs to open an
> > appropriate device. It takes a device path and a module name, both are
> > optional, as parameters. If a device path is specified, it will try to
> > open the given device. Otherwise it will try all available devices. If
> > only a specific subset is desired, the module parameter can be used as
> > a filter. The function will use it to open only devices whose kernel
> > driver matches the given module name.
> >
> > Instead of relying on the legacy drmOpen() function to do this, convert
> > util_open() to use the new drmDevice helpers. This gets it functionally
> > much closer to what other DRM/KMS users, such as the X.Org Server or a
> > Wayland server, do.
> >
> > Signed-off-by: Thierry Reding <treding@nvidia.com>
> > ---
> > tests/util/kms.c | 167 +++++++++++++++++++++++++++++++++++++++++--------------
> > tests/util/kms.h | 43 ++++++++++++++
> > 2 files changed, 168 insertions(+), 42 deletions(-)
> >
> > diff --git a/tests/util/kms.c b/tests/util/kms.c
> > index d866398237bb..c5d35ab616d1 100644
> > --- a/tests/util/kms.c
> > +++ b/tests/util/kms.c
>
> > +int util_get_devices(drmDevicePtr **devicesp, uint32_t flags)
> Personally I would not have bothered with this helper, but it's nice to have ;-)
Yeah, I added this after realizing that I was typing the same code
sequence for the second time.
> > +{
>
> > + if (!devicesp)
> > + return err;
> > +
>
> > +
> > + if (devicesp)
> With the "if !devicesp" check above this should always be true, no ?
Yes, you're absolutely right. I added the above shortcut in a very late
iteration and forgot to update the tail of the function.
> > +int util_open_with_module(const char *device, const char *module)
> Name and thus distinction vs util_open is blurred - here we require
> non-null device... which we should check for.
Yes, I've added a check for that now.
> Sadly I'm out of ideas for better name(s) :-(
I know this isn't ideal, but hopefully the doxygen in patch 3/3 will
clarify somewhat how these are to be used.
>
> > {
> > - int fd;
> > + int fd, err = 0;
> > +
> > + if (module)
> > + printf("trying to open `%s' with `%s'...", device, module);
> > + else
> > + printf("trying to open `%s'...", device);
> > +
> > + fd = open(device, O_RDWR);
> Not sure how much we should care here, but O_CLOEXEC would be nice.
Yes, added.
> > +int util_open(const char *device, const char *module)
> > +{
>
>
> > + } else {
> > + fd = util_open_with_module(device, module);
> Nit: one can drop a level of indentation/brackets - I have no strong
> preference either way.
>
> int util_open(...)
> {
> if (device)
> return util_open_with_module(device, module);
>
> ...
> get_devices
> ...
> }
This looks better indeed. It's also nice how the implementation now very
closely matches the description in the doxygen comment introduced in
patch 3/3.
> > --- a/tests/util/kms.h
> > +++ b/tests/util/kms.h
>
> > +
> > +static inline char *util_device_get_node(drmDevicePtr device,
> > + unsigned int type)
> > +{
> > + if (type >= DRM_NODE_MAX)
> > + return NULL;
> > +
> IMHO it's better to honour the ::available_nodes bitmask here, since
> we already check if we're within range.
This was meant to be a very low-level accessor that can be used to
implement the iterators rather than be used standalone. If you look at
the util_device_for_each_{,available}_node iterators, they make a
distinction, though it is admittedly somewhat questionable how useful
the iterator over all nodes, available or not, really is.
It's probably best to just drop the util_device_for_each() iterator
altogether.
> This the above the series is
> Reviewed-by: Emil Velikov <emil.l.velikov@gmail.com>
Thanks,
Thierry
[-- Attachment #1.2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2017-02-01 15:59 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-30 10:29 [PATCH libdrm 1/3] tests/util: Reindent using editorconfig settings Thierry Reding
2017-01-30 10:29 ` [PATCH libdrm 2/3] tests/util: Make util_open() use drmDevice Thierry Reding
2017-02-01 12:47 ` Emil Velikov
2017-02-01 15:59 ` Thierry Reding [this message]
2017-01-30 10:29 ` [PATCH libdrm 3/3] tests/util: Add some API documentation Thierry Reding
2017-01-30 10:32 ` [PATCH libdrm 1/3] tests/util: Reindent using editorconfig settings Thierry Reding
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170201155932.GA18725@ulmo.ba.sec \
--to=thierry.reding@gmail.com \
--cc=dri-devel@lists.freedesktop.org \
--cc=emil.l.velikov@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox