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

[Hans de Goede]

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.

Regards,

Hans