Re: [GSoC] Porting GuixSD to GNU/Hurd Update
Manolis Ragkousis, on Sat 20 Aug 2016 21:31:43 +0300, wrote: > On 08/20/16 20:47, Samuel Thibault wrote: > > Ok, but the Linux part uses glibc 2.22, and you'd rather use it, right? > > Of course :-) Ok, I have pushed it, along the debian glibc 2.22 fixup patches, it seems to be working fine with the i586 build. About the i686 build, we actually had to make it work in Debian to have issues with departing from other ports. It seems that the issue we have is with ifunc, and so we are using export libc_cv_ld_gnu_indirect_function=no to just disable ifunc for now. You'll probably want to do the same. Samuel
Re: [PATCH] Introduce gsync-based locks to glibc.
Samuel Thibault, on Sat 20 Aug 2016 22:41:37 +0200, wrote: > The good news is that there are only half a dozen test regressions. The even more good news is that these are most probably actually due to a bogus DNS resolution configuration on my system :) Samuel
Re: [PATCH] Introduce gsync-based locks to glibc.
Hello, Agustina Arzille, on Fri 20 May 2016 00:43:37 -0300, wrote: > Here are the patches needed to get the ball rolling and finally introduce > gsync-based synchronization objects into our libc. Thanks to the coach back home, I got the time to have a look at integrating this. The good news is that there are only half a dozen test regressions. I'll try to boot with it, rebuild static servers with it, etc. and will probably upload that to Debian for now (so that we have a clearly separate version including only these first bits). Samuel
Re: [GSoC] Porting GuixSD to GNU/Hurd Update
On 08/20/16 20:47, Samuel Thibault wrote: > Ok, but the Linux part uses glibc 2.22, and you'd rather use it, right? Of course :-)
Re: [GSoC] Porting GuixSD to GNU/Hurd Update
Manolis Ragkousis, on Sat 20 Aug 2016 20:42:25 +0300, wrote: > Actually the Hurd part of Guix uses 2.19 as it is in > ftp://alpha.gnu.org/gnu/hurd/ > > The glibc tarballs use 2.19 as their version, which is the one I am > using as the version in our glibc/hurd recipe. Ok, but the Linux part uses glibc 2.22, and you'd rather use it, right? Samuel
Re: [GSoC] Porting GuixSD to GNU/Hurd Update
Hey Samuel, Actually the Hurd part of Guix uses 2.19 as it is in ftp://alpha.gnu.org/gnu/hurd/ The glibc tarballs use 2.19 as their version, which is the one I am using as the version in our glibc/hurd recipe. Check (gnu packages base) glibc/hurd. Manolis On 08/20/16 19:24, Samuel Thibault wrote: > Hello, > > Which glibc version is guix based on? It's very high time we upgrade > our glibc repository, because we see people contribute patch against > it and it makes use rebase the work in downstreams. I'd thus say we > should make our glibc repository based on the minimum version used by > the supported distros (i.e. debian & guix). Debian is currently at 2.23 > and will soon move to 2.24, a quick grep on the Guix-on-Hurd repository > seems to be showing glibc 2.22, so we could use 2.22 for now? > > Samuel >
Re: [PATCH] Re: Hurd shutdown problems
Hello, Brent W. Baccala, on Wed 17 Aug 2016 10:58:41 -1000, wrote: > OK, I seem to have gotten a handle on this thing now. Cool :) > First, there's a missing mutex unlock in mach_defpager. I'm attaching two > patches. One fixes the debug printfs in mach_defpager/default_pager.c, which > obviously haven't been compiled for a while. Use %p and %lx instead of %x to > silence compiler warnings, and access pthread_mutex_t's internal structure > member __held instead of held when printing mutex state. The second patch > actual fixes the problem. Applied, thanks! > Second, the sysvinit scripts are killing mach_defpager during the shutdown > sequence, > The big culprit is /sbin/killall5, a C program in the sysvinit-utils > package. Oh, that's no good indeed. > killall5's internal logic is just too Linux specific, IMHO. What's the > Hurdish > way to do it? I'm thinking killall5 should check that 'important' flag on the > process and skip processes for which that flag is set. Yet, I don't > understand > what that flag is really intended for. Does this make sense? You can check the changelog of the commit that introduced it: git show 5f536bc5 It was specifically meant for dealing with killall5. See the proc_is_important use in procfs: proc_is_important (p, ); if (essential) start_code = end_code = 0; /* To make killall5.c consider it a kernel process that is to be left alone. */ i.e. we rely on killall5 considering that start/end code being 0 means it's a kernel thingy, which is true here from the point of view of a posix program. So the real fix indeed is to mark mach-defpager as important. Could you have a look at submitting a tested patch for this? > Also, what should the kernel do if it has problems with the default pager? Get errors, probably :) > After I fixed the mutex bug, I started getting a bunch of > memory_object_data_request failed messages on console. Still mysterious, but > I > guess that's better than nothing! The error code prints in hex, and when I > looked it up it was MACH_SEND_INVALID_DEST. Is that what you get when you > send > to a dead port? IIRC yes. > Also, there's this proxy-defpager. Is that the actual default pager, acting > as > front end to mach-defpager? See git grep proxy-defpager in the source: “ The new proxy-defpager translator grants unprivileged users access to the default pager. ” It'd be good if someone could document it in the right places (hurd documentation, hurd wiki pages about the translators, etc.) > Yet killall5 seems to be able to kill > proxy-defpager without consequence. I don't understand. the proxy-defpager is used by non-root applications, probably at the killall5 point there are not supposed to be any one of them any more. > For me, though, I now have a qemu VM that can cleanly start up, use swap, and > shutdown, so I have real sense of accomplishment! And it'll definitely be helpful for others, thanks! Samuel
Re: To be talked about at ghm?
Svante Signell, on Thu 18 Aug 2016 16:12:38 +0200, wrote: > On Thu, 2016-08-18 at 14:10 +0200, Samuel Thibault wrote: > > Samuel Thibault, on Wed 17 Aug 2016 18:14:39 +0200, wrote: > > > On friday, I'll present the latest news of the Hurd. > > > > Actually I was asked to do it today, so it's over already :) > > I looked at your presentation, nice! Did you get any feedback? Well, as usual "- really promising! When will I be able to run it on my laptop? - you can already, but perhaps your network board won't be supported, you're welcome to work on that - ah..." So people are happy to see the Hurd moving forward, but seem to keep not understanding that if they want to run it it'd be good that they just help. It's a bit depressing to see how people have forgotten that it's just the same situation as in the old days of Linux, and not so much effort needs to be done, but it still seems too much for people... Anyway, as I said in my talk: thanks a lot to everybody who have contributed in the past years, basically all the new stuff I've presented was yours :) Samuel
