Looks like __FreeBSD_kernel__ means just the same as __FreeBSD__ ?

__FreeBSD__ is defined when a complete freebsd system (kernel + libC) is used.

__FreeBSD_kernel__ is only defined when a freebsd kernel is used (and the GNU libC)


Some information from debian http://glibc-bsd.alioth.debian.org/porting/PORTING

Other than the gthread-posix change, it looks like all of these are related to credentials stuff. Maybe we should just have a configure check for HAVE_STRUCT_CMSGCRED, and use that. (I was going to add "and then maybe it will work on NetBSD, OpenBSD, and OS X too", but from googling, it looks like each one is different here...)

(In reply to comment #3)
> Other than the gthread-posix change, it looks like all of these are related to
> credentials stuff. Maybe we should just have a configure check for
> HAVE_STRUCT_CMSGCRED, and use that. (I was going to add "and then maybe it will
> work on NetBSD, OpenBSD, and OS X too", but from googling, it looks like each
> one is different here...)

Yeah, I think I'd like that approach better.

The thread priority stuff is obsolete now, since GLib no longer supports thread priorities.

In Debian we've recently had to (re-)apply essentially the same change as the credentials stuff here, to make GDBus able to connect to D-Bus on kFreeBSD at all - it seems the other authentication code path, using cookie files in the home directory, doesn't work there, or something? (I haven't debugged it yet, but I suspect it's less reliable for unusual uses where there might not be a home directory, like the gdm3 mini-GNOME-session, in any case.) So I'd like to not make the perfect the enemy of the good here.

(In reply to comment #3)
> Maybe we should just have a configure check for
> HAVE_STRUCT_CMSGCRED, and use that.

libdbus does this sort of thing. It has the disadvantage that it's impossible for a non-guru to tell which mechanism(s) we expect to use on which platform(s). We seem to have at least 5½ mechanisms:

* send via struct cmsgcred in SOL_SOCKET SCM_CREDS header,
  receive struct cmsgcred
* send via setsockopt(0, LOCAL_CREDS), receive struct cmsgcred
* send implicitly (?), receive via getsockopt(SOL_SOCKET, SO_PEERCRED)
  into struct sockpeercred (for OpenBSD)
* send implicitly (?), receive via getsockopt(SOL_SOCKET, SO_PEERCRED)
  into struct ucred (for some unspecified non-OpenBSD OS - this is the ½)
* send implicitly (?), receive via getpeereid()
* send implicitly (?), receive via getpeerucred() and possibly
  a Solaris audit session

but all I can tell about platforms from that is that sockpeercred is OpenBSD, and getpeerucred() is presumably Solaris.

Worse, there apparently exist platforms where more than one of those exists, so we have code like this where the order matters:

    #if defined(HAVE_CMSGCRED)
      /* NOOP just to make sure only one codepath is used
       *      and to prefer CMSGCRED
       */
    #elif defined(LOCAL_CREDS)

As a result, I prefer GLib's current approach. There seem to be nearly as many versions of credentials-passing as there are OSs, so I don't expect many code paths can be shared in practice; and credentials-passing seems to be hairy enough that we can't really claim it works on any OS where it hasn't explicitly been tested.

Created attachment 227719 [details] [review]
updated patch (with the same "whitelist of OSs" approach as before)

Comment on attachment 227719 [details] [review]
updated patch (with the same "whitelist of OSs" approach as before)

ok, given that every single BSD implements creds differently, it seems like having the explicit kernel ifdef is better than trying to figure it out based on HAVE_whatever_data_type.

(though maybe the GNU/FreeBSD people should get FreeBSD to #define __FreeBSD_kernel_ too...)

Fixed in git:

1afaea3 for 2.35.2
11f26aa for 2.34.2
7a3f70e for 2.32.5 (if there is one), since Debian 7 will have 2.32