From: walter harms <wharms-fPG8STNUNVg@public.gmane.org>
To: Thierry Reding <thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Cc: xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Subject: Re: [PATCH libdrm v3 2/5] xf86drm: Add USB support
Date: Sat, 21 Jan 2017 18:44:50 +0100 [thread overview]
Message-ID: <58839E12.2050507@bfs.de> (raw)
In-Reply-To: <20170119102038.GB30182-EkSeR96xj6Pcmrwk2tT4+A@public.gmane.org>
Am 19.01.2017 11:20, schrieb Thierry Reding:
> Adding back dri-devel@lists.freedesktop.org
>
> On Wed, Jan 18, 2017 at 12:21:23PM +0100, walter harms wrote:
>>
>>
>> Am 18.01.2017 10:02, schrieb Thierry Reding:
>>> Allow DRM/KMS devices hosted on USB to be detected by the drmDevice
>>> infrastructure.
>>>
>>> v3:
>>> - guard Linux-specific sysfs parsing code with #ifdef __linux__
>>>
>>> v2:
>>> - make sysfs_uevent_get() more flexible using a format string
>>>
>>> Signed-off-by: Thierry Reding <thierry.reding@gmail.com>
>>> ---
>>> xf86drm.c | 175 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
>>> xf86drm.h | 13 +++++
>>> 2 files changed, 188 insertions(+)
>>>
>>> diff --git a/xf86drm.c b/xf86drm.c
>>> index 7766bfe937db..d83674e638c4 100644
>>> --- a/xf86drm.c
>>> +++ b/xf86drm.c
>>> @@ -2886,6 +2886,50 @@ char *drmGetRenderDeviceNameFromFd(int fd)
>>> return drmGetMinorNameForFD(fd, DRM_NODE_RENDER);
>>> }
>>>
>>> +#ifdef __linux__
>>> +static char * DRM_PRINTFLIKE(2, 3)
>>> +sysfs_uevent_get(const char *path, const char *fmt, ...)
>>> +{
>>> + char filename[PATH_MAX + 1], *key, *line = NULL, *value = NULL;
>> char *filename=NULL, *key, *line = NULL, *value = NULL;
>>> + size_t size = 0, len;
>>> + ssize_t num;
>>> + va_list ap;
>>> + FILE *fp;
>>> +
>>> + va_start(ap, fmt);
>>> + num = vasprintf(&key, fmt, ap);
>>> + va_end(ap);
>>> + len = num;
>>> +
>>> + snprintf(filename, sizeof(filename), "%s/uevent", path);
>>
>> since asprintf() is available you could use:
>>
>> asprintf(&filename,"%s/uevent", path);
>>
>> same could be done for path below.
>
> I had thought about that, but a stack-allocated string seemed
> advantageous for three reasons:
>
> - asprintf() is a GNU extension. That's not much of an issue
> because this is already protected by #ifdef __linux__ and
> pretty much all C libraries I know support asprintf() and
> friends.
>
> - PATH_MAX is the maximum length of a filename, so there's no
> need to dynamically allocate, since it should nicely fit into
> the stack pretty much everywhere (I think the largest value I
> have ever seen for PATH_MAX is 4096 on recent Linux systems).
>
> - Most of the other code in xf86drm.c already uses PATH_MAX, so
> the code remains consistent.
>
> Given the added complexity of asprintf() and the need to free the memory
> the advantages of the stack-allocated string seemed to outweigh.
>
> Thierry
Granted,
I like to use asprintf every time %s is used to stop malicious users in the tracks
(do not aks me how this could be done with our function). Freeing the allocated buf
is no practical problem. NTL i have no problem if you are happy with the patch, making
an informed decision is ok with me.
re,
wh
_______________________________________________
xorg-devel@lists.x.org: X.Org development
Archives: http://lists.x.org/archives/xorg-devel
Info: https://lists.x.org/mailman/listinfo/xorg-devel
next prev parent reply other threads:[~2017-01-21 17:44 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-01-18 9:02 [PATCH libdrm v3 0/5] xf86drm: Add USB, platform and host1x bus support Thierry Reding
2017-01-18 9:02 ` [PATCH libdrm v3 1/5] xf86drm: Factor out drmDeviceAlloc() Thierry Reding
[not found] ` <20170118090209.13819-1-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-01-18 9:02 ` [PATCH libdrm v3 2/5] xf86drm: Add USB support Thierry Reding
[not found] ` <587F4FB3.2070006@bfs.de>
2017-01-19 10:20 ` Thierry Reding
[not found] ` <20170119102038.GB30182-EkSeR96xj6Pcmrwk2tT4+A@public.gmane.org>
2017-01-21 17:44 ` walter harms [this message]
2017-01-18 9:02 ` [PATCH libdrm v3 3/5] xf86drm: Add platform and host1x bus support Thierry Reding
[not found] ` <587F8304.90105@bfs.de>
2017-01-19 10:25 ` Thierry Reding
[not found] ` <20170118090209.13819-4-thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
2017-01-20 14:03 ` Emil Velikov
2017-01-18 9:02 ` [PATCH libdrm v3 4/5] tests/drmdevice: Add USB, platform and host1x support Thierry Reding
2017-01-18 9:02 ` [PATCH libdrm v3 5/5] xf86drm: Reuse sysfs_uevent_get() 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=58839E12.2050507@bfs.de \
--to=wharms-fpg8stnunvg@public.gmane.org \
--cc=dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
--cc=thierry.reding-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
--cc=xorg-devel-go0+a7rfsptAfugRpC6u6w@public.gmane.org \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.