dri-devel Archive on lore.kernel.org
 help / color / mirror / Atom feed
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

  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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox