On 02/24/2016 06:15 AM, Jan Pokorný wrote: > On 24/02/16 12:45 +0100, Svante Signell wrote: >> On Fri, 2016-02-19 at 13:09 +0100, Jan Pokorný wrote: >>> On 19/02/16 11:40 +0100, Svante Signell wrote: >>>> The attached patch, hurd_support.patch, against git master adds support for >>>> the >>>> GNU/Hurd OS. Please consider including this patch to upstream git. It has >>>> already been reported in Debian as bug #803777 against version >>>> 0.17.2.real-4, >>>> see https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=803777 >>> >>> thanks for you contribution. Currently, the preferred patchflow is via >>> pull requests on GitHub against https://github.com/ClusterLabs/libqb. >>> >>> If it doesn't cause you a lot of troubles, could you please forward your >>> patches in this direction? >>> >>> Otherwise, please at least send full git-formatted patches (git >>> format-patch or, even better, git send-email) so that the patch >>> authorship is properly tracked. >> >> Attached are two git-formatted patches against the latest git. In order to >> issue >> a git pull request, I'd need an account on github, right? > > I made the PR on your behalf (it seems you already posses a GH > account, BTW.): https://github.com/ClusterLabs/libqb/pull/187
I added this comment to the pull request: * The leading null byte in sun_path (the "+ 1" when using it) indicates an abstract socket (see unix(7)). If Hurd doesn't support those, it'll need a separate block -- we shouldn't change the behavior for Linux/Cygwin. * I don't think the unlink() will make sense with abstract sockets. * Not necessary with this request, but it would be nice if we could have ./configure define semantic macros like HAVE_ABSTRACT_SOCKET or something. Or at least #define them ourselves so we don't have to repeat "defined(...) || ..." all the time. > But feel free to supersede it with your own. > >> 0001-Add-hurd-support.patch >> 0002-Fix-address.sun_path-in-lib-ipc_setup.c-and-lib-ipc_.patch >> >> Thanks! > > You're welcome! _______________________________________________ Developers mailing list [email protected] http://clusterlabs.org/mailman/listinfo/developers
