Hi On Fri, Feb 21, 2014 at 8:30 AM, Thierry Reding <thierry.reding@xxxxxxxxx> wrote: > On Wed, Feb 12, 2014 at 02:36:24PM +0100, Daniel Vetter wrote: >> On Wed, Jan 29, 2014 at 03:01:58PM +0100, David Herrmann wrote: >> > Whenever we access minor->device, we are in a minor->kdev->...->fops >> > callback so the minor->kdev pointer *must* be valid. Thus, simply use >> > minor->kdev->devt instead of minor->device and remove the redundant field. >> > >> > Signed-off-by: David Herrmann <dh.herrmann@xxxxxxxxx> >> >> I think this is simply compat cruft from the days when the drm core was >> still shared with the *bsds. With the one patch I've commented on all >> patches up to this one are >> >> Reviewed-by: Daniel Vetter <daniel.vetter@xxxxxxxx> >> >> As discussed on irc I think we don't want to have stable minor ids really, >> userspace simply needs to inquire udev to get at the right >> render/control/legacy node it wants. > > Does that mean we should go all the way and don't keep the +64 (for > control) and +128 (for render nodes) offsets either? Should it be > possible to have a /dev/dri directory that looks somewhat like this: > > /dev/dri/card0 (GPU#0, legacy) > /dev/dri/card1 (GPU#1, legacy) > /dev/dri/render0 (GPU#1, render) That might break backwards compat, but may be worth it. However, we *have* to keep the +64 / +128 offsets for minor numbers. There's already user-space using that for dev-type testing (which is fine!). Thanks David _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/dri-devel