[PATCH v2 04/14] xf86Xinput: Modify API for server-managed fd support

[Mark Kettenis]

> Date: Wed, 05 Feb 2014 13:13:04 +0100
> From: Hans de Goede <hdegoede at redhat.com>
> 
> Hi,
> 
> On 02/05/2014 12:50 PM, Mark Kettenis wrote:
> >> Date: Tue, 04 Feb 2014 16:44:07 +0100
> >> From: Hans de Goede <hdegoede at redhat.com>
> >>
> >> Hi,
> >>
> >> On 02/04/2014 02:12 PM, Mark Kettenis wrote:
> >>>> Date: Tue, 04 Feb 2014 13:16:21 +0100
> >>>> From: Hans de Goede <hdegoede at redhat.com>
> >>>>
> >>>> The systemd-logind API uses separate major and minor numbers rather
> >>>> then a dev_t.
> >>>
> >>> I don't think the design of the Xorg driver API should be blindly
> >>> copied from Linux-specific APIs.
> >>>
> >>> The integration of systemd support in Xorg gives me an uneasy feeling.
> >>> For us OpenBSD developers systemd is an example of the sort of
> >>> complexity that we think is responsible for many of the security
> >>> issues in software.  I would feel much more at ease if it would be
> >>> firmly jailed in hw/xfree86/os-support/linux.
> >>>
> >>>> Also I don't want to leak the platform specific dev_t type into
> >>>> public headers.
> >>>
> >>> That is a valid point; having to include <sys/stat.h> everywhere would
> >>> probably be a bad idea.
> >>>
> >>> Not quite convinced why you need to add major and minor to the Xorg
> >>> driver API though.  Since you have the file descriptor, you can easily
> >>> call stat(2) to find out.
> >>
> >> We're getting the file-descriptor from logind on both init and vtenter,
> >> in order to get if from logind we need to pass it a major + minor, note
> >> that at this point we don't have a fd yet, so nothing to fstat.
> >
> > Ah, so udev gives you the major/minor which you then feed to
> > systemd/logind, which passes back the file descriptor, which is then
> > handed over to the driver.  Thanks for the explanation.
> 
> You're welcome.
> 
> <snip>
> 
> > On that same subject, putting the systemd_logind_xxx() calls directly
> > into xf86NewInputDevice() function seems like a bad idea to me as
> > well.  I can see a use case for server managed file descriptors on
> > OpenBSD as well as it could be used to hide the privsep implementation
> > from the drivers.
> 
> Good, my plan is to wait for a second user to come up, and then we can
> rename the functions and have multiple providers of them, just like
> we have for the config_foo stuff. IOW I'm very much open to making this
> more generic, but it seems more sensible to delay doing that till we've
> at least 2 providers of server managed fds. Note that these bits are
> all completely internal so they can be changed at any times.

Fair enough; happy to hear you're aware of the issues.