Date: Tue, 11 Aug 2015 15:53:29 +0200 From: Koop Mast <kwm@FreeBSD.org> To: Jan Beich <jbeich@FreeBSD.org> Cc: svn-src-head@freebsd.org, svn-src-all@freebsd.org, src-committers@freebsd.org Subject: Re: svn commit: r286524 - in head: . etc sys/dev/drm sys/dev/drm2 Message-ID: <1439301209.4375.40.camel@FreeBSD.org> In-Reply-To: <bneg-f17o-wny@FreeBSD.org> References: <201508091258.t79CwvGj027161@repo.freebsd.org> <bneg-f17o-wny@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 2015-08-10 at 02:15 +0200, Jan Beich wrote: > Koop Mast <kwm@FreeBSD.org> writes: > > > Author: kwm (ports committer) > > Date: Sun Aug 9 12:58:56 2015 > > New Revision: 286524 > > URL: https://svnweb.freebsd.org/changeset/base/286524 > > > > Log: > > Add a new group named 'video' with the id of 44. And make drm > > create > > devices in /dev/dri/ with this new group. > > Would 'video' group include capture devices as well? Linux seems to > mix > /dev/nvidia*, /dev/fb* and /dev/video* all under same group despite > all of them have different attack vectors. We could extend this, but the only example I had where the dri devices. Also webcamd already chmod's it's devices: % ll /dev/video0 crw-rw---- 1 webcamd webcamd 0x9a Aug 10 07:35 /dev/video0 I'm unsure if nvidia makes any /dev devices since it been ages since I had one in a machine of mine. > > Modified: head/sys/dev/drm/drmP.h > > =================================================================== > > =========== > > --- head/sys/dev/drm/drmP.h Sun Aug 9 12:20:22 2015 > > (r286523) > > +++ head/sys/dev/drm/drmP.h Sun Aug 9 12:58:56 2015 > > (r286524) > > @@ -175,7 +175,7 @@ SYSCTL_DECL(_hw_drm); > > > > #define DRM_DEV_MODE (S_IRUSR|S_IWUSR|S_IRGRP|S_IWGRP) > > #define DRM_DEV_UID 0 > > -#define DRM_DEV_GID 0 > > +#define DRM_DEV_GID 44 /* "video" group */ > > Why hardcode? Linux often uses udev(7) rules to assign a group which > on > FreeBSD can easily be translated into devd.conf(5) or devfs.rules(5). > > Having 'video' assigned by kernel wouldn't eliminate having to run > mergemaster/etcupdate + pw groupmod on upgrade. I find this way easier to do. However with the devd.conf(5) or devfs.rules(5) someone still needs to up date the /etc and pw groupmod. -Koop
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1439301209.4375.40.camel>