Re: Upstreaming the glibc Hurd port

Florian Weimer, on jeu. 18 janv. 2018 13:39:51 +0100, wrote: > Is it just a matter of someone doing the work of upstreaming all the > existing patches? It's mostly that, yes. > If we cannot resolve this is in the coming months, I think we should > seriously consider a removal of the Hurd port, I'

Re: Upstreaming the glibc Hurd port

Samuel Thibault, on jeu. 18 janv. 2018 13:45:37 +0100, wrote: > Unless bug-hurd people actually help me with it. FI, in my previous glibc upstream build attemps, I came up with the following list of patches which are required for upstream glibc to build at all. Most of them don't have changelog, h

Re: Upstreaming the glibc Hurd port

Please note (as a reminder from past discussions) that the Hurd libpthread will need to be included as part of glibc, much like NPTL is a fully-integrated part of glibc - not a separate package (support for add-ons has been removed from glibc). (I'd also suggest that it *not* use a top-level d

Re: Upstreaming the glibc Hurd port

Samuel Thibault, on jeu. 18 janv. 2018 14:40:37 +0100, wrote: > I came up with the following list of patches They are usually more or less named like the corresponding topgit branch in our glibc repo. The .topmsg file can be use to track what work has been done on the patch (checking formatting, c

Re: Upstreaming the glibc Hurd port

Incidentally, Samuel did post the Hurd TLS support three years ago . Roland's review comments should of course be considered, though the current Hurd port maintainers are free to decide they disagree with particular aspects of those c

Re: Upstreaming the glibc Hurd port

Joseph Myers, on jeu. 18 janv. 2018 13:47:42 +, wrote: > Please note (as a reminder from past discussions) that the Hurd libpthread > will need to be included as part of glibc, much like NPTL is a > fully-integrated part of glibc - not a separate package (support for > add-ons has been remov

Re: Upstreaming the glibc Hurd port

On 01/18/2018 01:45 PM, Samuel Thibault wrote: Florian Weimer, on jeu. 18 janv. 2018 13:39:51 +0100, wrote: Is it just a matter of someone doing the work of upstreaming all the existing patches? It's mostly that, yes. Good to know, thanks. The question is how we can do this incrementally (s

Re: Upstreaming the glibc Hurd port

Joseph Myers, on jeu. 18 janv. 2018 13:52:32 +, wrote: > Incidentally, Samuel did post the Hurd TLS support three years ago > . Roland's > review comments should of course be considered, Yes, it has been on my TODO list for as long

Re: Upstreaming the glibc Hurd port

On Thu, 18 Jan 2018, Samuel Thibault wrote: > > Before Hurd support is fully integrated in glibc, I'd encourage having a > > branch *in the glibc repository* that contains such support, so we can > > more readily see what the changes yet to be merged are (and possibly > > comment on issues that

Re: Upstreaming the glibc Hurd port

Hi! Despite my good intentions, in the past year (or even longer...) I failed to allocate sufficient time to do any substantial work on the Hurd side, but I'll now allocate time to at least help with... On Thu, 18 Jan 2018 14:57:58 +0100, Samuel Thibault wrote: > Joseph Myers, on jeu. 18 janv.

Re: Upstreaming the glibc Hurd port

Thomas Schwinge, on jeu. 18 janv. 2018 15:22:09 +0100, wrote: > > I can pile-commit what we currently have, with all the XXXs, FIXMEs, > > etc., if that can help the glibc side. > > I'm not sure if that's a useful thing to spend time on, right now. I > think it'll be better if we first integrate

Re: Upstreaming the glibc Hurd port

Joseph Myers, on jeu. 18 janv. 2018 13:47:42 +, wrote: > (I'd also suggest that it *not* use a top-level directory called > simply "libpthread" or similar without mention of Hurd, as that would > be too confusing to people looking at the source tree for pthreads for > other platforms.) Sure :)

Re: Upstreaming the glibc Hurd port

Thomas Schwinge, on jeu. 18 janv. 2018 15:22:09 +0100, wrote: > Despite my good intentions, in the past year (or even longer...) I failed > to allocate sufficient time to do any substantial work on the Hurd side, > but I'll now allocate time to at least help with... > > On Thu, 18 Jan 2018 14:57:5

Re: Upstreaming the glibc Hurd port

On Thu, 18 Jan 2018, Samuel Thibault wrote: > Joseph Myers, on jeu. 18 janv. 2018 13:47:42 +, wrote: > > (I'd also suggest that it *not* use a top-level directory called > > simply "libpthread" or similar without mention of Hurd, as that would > > be too confusing to people looking at the sour

Re: Upstreaming the glibc Hurd port

On Thu, 18 Jan 2018, Samuel Thibault wrote: > Coding standards can be worked on by anybody, this is really something > that bug-hurd people can unload us from. Which is also something that having a branch with the patches is helpful for - it allows glibc people to look over them and point out co

Re: Upstreaming the glibc Hurd port

Joseph Myers, on jeu. 18 janv. 2018 15:34:56 +, wrote: > On Thu, 18 Jan 2018, Samuel Thibault wrote: > > Coding standards can be worked on by anybody, this is really something > > that bug-hurd people can unload us from. > > Which is also something that having a branch with the patches is help

Re: Upstreaming the glibc Hurd port

On Thu, 18 Jan 2018, Samuel Thibault wrote: > Joseph Myers, on jeu. 18 janv. 2018 15:34:56 +, wrote: > > On Thu, 18 Jan 2018, Samuel Thibault wrote: > > > Coding standards can be worked on by anybody, this is really something > > > that bug-hurd people can unload us from. > > > > Which is als

Re: Upstreaming the glibc Hurd port

Joseph Myers, on jeu. 18 janv. 2018 16:47:55 +, wrote: > On Thu, 18 Jan 2018, Samuel Thibault wrote: > > > Joseph Myers, on jeu. 18 janv. 2018 15:34:56 +, wrote: > > > On Thu, 18 Jan 2018, Samuel Thibault wrote: > > > > Coding standards can be worked on by anybody, this is really something

Re: Upstreaming the glibc Hurd port

Joseph Myers, on jeu. 18 janv. 2018 16:47:55 +, wrote: > On Thu, 18 Jan 2018, Samuel Thibault wrote: > > Not all of them are necessary for managing to build glibc. Some of them > > are just hacking, others are perhaps almost ready to commit, just > > missing changelogs & formatting. That's the

Hurd lecture

Hi - FYI, I gave an hour and a half Hurd lecture yesterday at Catholic University in Washington, D.C. I put a screencast of the lecture on youtube: https://www.youtube.com/watch?v=JwsuAEF2FYE The first part of the video is a general discussion of high performance computing, leading into my own

Re: Upstreaming the glibc Hurd port

On Thu, 18 Jan 2018, Samuel Thibault wrote: > That's why I meant work is needed to sort out what we want to show > people. Which takes triaging time, back to square 0. I sent to the > bug-hurd list the list of patches which was enough at some point to get > glibc buildable, that's what should be w

Re: Upstreaming the glibc Hurd port

Joseph Myers, on jeu. 18 janv. 2018 23:15:59 +, wrote: > Thanks for the changes pushed to sthibaul/hurd-builds so far (I realise > there will be more to get it into a buildable state, e.g. the actual > libpthread implementation). What I have pushed is basically only missing the libpthread im

Re: Upstreaming the glibc Hurd port

On Fri, 19 Jan 2018, Samuel Thibault wrote: > Joseph Myers, on jeu. 18 janv. 2018 23:15:59 +, wrote: > > Thanks for the changes pushed to sthibaul/hurd-builds so far (I realise > > there will be more to get it into a buildable state, e.g. the actual > > libpthread implementation). > > What