From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thierry Reding Subject: Re: [PATCH libdrm v3 2/5] xf86drm: Add USB support Date: Thu, 19 Jan 2017 11:20:38 +0100 Message-ID: <20170119102038.GB30182@ulmo.ba.sec> References: <20170118090209.13819-1-thierry.reding@gmail.com> <20170118090209.13819-3-thierry.reding@gmail.com> <587F4FB3.2070006@bfs.de> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1669169255==" Return-path: Received: from mail-wm0-x242.google.com (mail-wm0-x242.google.com [IPv6:2a00:1450:400c:c09::242]) by gabe.freedesktop.org (Postfix) with ESMTPS id 4CC8A6E9B4 for ; Thu, 19 Jan 2017 10:20:41 +0000 (UTC) Received: by mail-wm0-x242.google.com with SMTP id d140so10880762wmd.2 for ; Thu, 19 Jan 2017 02:20:41 -0800 (PST) In-Reply-To: <587F4FB3.2070006@bfs.de> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dri-devel-bounces@lists.freedesktop.org Sender: "dri-devel" To: walter harms Cc: xorg-devel@lists.x.org, dri-devel@lists.freedesktop.org List-Id: dri-devel@lists.freedesktop.org --===============1669169255== Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="V0207lvV8h4k8FAm" Content-Disposition: inline --V0207lvV8h4k8FAm Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Adding back dri-devel@lists.freedesktop.org On Wed, Jan 18, 2017 at 12:21:23PM +0100, walter harms wrote: >=20 >=20 > Am 18.01.2017 10:02, schrieb Thierry Reding: > > Allow DRM/KMS devices hosted on USB to be detected by the drmDevice > > infrastructure. > >=20 > > v3: > > - guard Linux-specific sysfs parsing code with #ifdef __linux__ > >=20 > > v2: > > - make sysfs_uevent_get() more flexible using a format string > >=20 > > Signed-off-by: Thierry Reding > > --- > > xf86drm.c | 175 ++++++++++++++++++++++++++++++++++++++++++++++++++++++= ++++++++ > > xf86drm.h | 13 +++++ > > 2 files changed, 188 insertions(+) > >=20 > > 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); > > } > > =20 > > +#ifdef __linux__ > > +static char * DRM_PRINTFLIKE(2, 3) > > +sysfs_uevent_get(const char *path, const char *fmt, ...) > > +{ > > + char filename[PATH_MAX + 1], *key, *line =3D NULL, *value =3D NULL; > char *filename=3DNULL, *key, *line =3D NULL, *value =3D NULL; > > + size_t size =3D 0, len; > > + ssize_t num; > > + va_list ap; > > + FILE *fp; > > + > > + va_start(ap, fmt); > > + num =3D vasprintf(&key, fmt, ap); > > + va_end(ap); > > + len =3D num; > > + > > + snprintf(filename, sizeof(filename), "%s/uevent", path); >=20 > since asprintf() is available you could use: >=20 > asprintf(&filename,"%s/uevent", path); >=20 > 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 --V0207lvV8h4k8FAm Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEiOrDCAFJzPfAjcif3SOs138+s6EFAliAkvMACgkQ3SOs138+ s6EonRAAqHXkN21EcuYoYT2S8HW4geXXQStmriD2FUt0SrBad6NATBjteeDiQhe8 zKvPgf9fZRZN3e6OzibsECm60tfWvMCvKUuri3HNoS/cbJtNTfUm3aouozNGNLv6 MbVFexFaxleR1l+iRApx9lAIBqtze3ANakyErcQOpaKGAEeVrb7hCWgimcI/QhFC qN0XLueEQyfT+B3DsUkYwY0Z8We1ivPDKj6RiVA3dfZvmdCLmtfTA3rEUiC2sy84 PtlglSIFaNejaJ+QrfQiTMUJvoIc1dR06KAMQZeU3WxYaS1xvmjryArngD+Bw1RN 0qA3MlLMuJvbamcFq5fvtXxK5tzfkP29gyQ17W6zOVvhDqDVOaXnR3rvut7ccmZz 2TVjUI9IAX97cKcbJgFcV6ApVij+260pUJjFST1GNzs6yrbG8IhMbusSeiqdHVa9 UuTndq4rhNWh+EcQx0dC63AlVNH/8kmYwqqcJRo4OErYP84zOVGIOkhgAMmR1Rrz 28Q1EwJC5ZH+J7rJHMXRz5fD+aF3VqpVa7KV5ul+AN8niH2+tlmAM4UFhbI7lNha sf4QZOzL9+Pqw/z8OFyTfeM0KbJCRXqHC5zftKmId4pLFpXjfZJSVu297I83nAJv GJ9GuLZ3PhT4X1x/61syeyzEE2DsHapGReHZUcnso/cw8w0Jcgc= =Zydn -----END PGP SIGNATURE----- --V0207lvV8h4k8FAm-- --===============1669169255== Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: base64 Content-Disposition: inline X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KZHJpLWRldmVs IG1haWxpbmcgbGlzdApkcmktZGV2ZWxAbGlzdHMuZnJlZWRlc2t0b3Aub3JnCmh0dHBzOi8vbGlz dHMuZnJlZWRlc2t0b3Aub3JnL21haWxtYW4vbGlzdGluZm8vZHJpLWRldmVsCg== --===============1669169255==--