> Date: Wed, 05 Feb 2014 13:13:04 +0100 > From: Hans de Goede <[email protected]> > > Hi, > > On 02/05/2014 12:50 PM, Mark Kettenis wrote: > >> Date: Tue, 04 Feb 2014 16:44:07 +0100 > >> From: Hans de Goede <[email protected]> > >> > >> Hi, > >> > >> On 02/04/2014 02:12 PM, Mark Kettenis wrote: > >>>> Date: Tue, 04 Feb 2014 13:16:21 +0100 > >>>> From: Hans de Goede <[email protected]> > >>>> > >>>> 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. _______________________________________________ [email protected]: X.Org development Archives: http://lists.x.org/archives/xorg-devel Info: http://lists.x.org/mailman/listinfo/xorg-devel
