Re: Release process & rolling new releases

2014-11-23 Thread David Michael
On Sun, Nov 23, 2014 at 4:01 PM, Justus Winter <4win...@informatik.uni-hamburg.de> wrote: > Quoting Samuel Thibault (2014-11-23 21:11:05) >> Hello, >> >> David Michael, le Wed 19 Nov 2014 19:39:43 -0500, a écrit : >> > The only issue was that /etc/hurd/runsystem.hurd didn't get installed. >> > I ta

Re: [PATCH hurd 1/2] libpager: make the request queue more memory-efficient

2014-11-23 Thread Samuel Thibault
Justus Winter, le Sun 23 Nov 2014 23:06:58 +0100, a écrit : > Previously, `pager_demuxer' allocated a chunk of memory for the > response message. But if memory gets scarce, the kernel will issue a > large number of paging requests to free up memory. In such a > situation, allocating memory is dan

Re: [PATCH hurd 2/2] libdiskfs: fix fabrication of protid

2014-11-23 Thread Samuel Thibault
Justus Winter, le Sun 23 Nov 2014 23:06:59 +0100, a écrit : > * libdiskfs/dir-init.c (diskfs_init_dir): Fix fabrication of protid. Ack. > --- > libdiskfs/dir-init.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/libdiskfs/dir-init.c b/libdiskfs/dir-init.c > index 4ef

[PATCH hurd 1/2] libpager: make the request queue more memory-efficient

2014-11-23 Thread Justus Winter
Previously, `pager_demuxer' allocated a chunk of memory for the response message. But if memory gets scarce, the kernel will issue a large number of paging requests to free up memory. In such a situation, allocating memory is dangerous. Fix this by not allocating space for the response message,

[PATCH hurd 2/2] libdiskfs: fix fabrication of protid

2014-11-23 Thread Justus Winter
* libdiskfs/dir-init.c (diskfs_init_dir): Fix fabrication of protid. --- libdiskfs/dir-init.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/libdiskfs/dir-init.c b/libdiskfs/dir-init.c index 4efded0..8301ca1 100644 --- a/libdiskfs/dir-init.c +++ b/libdiskfs/dir-init.c @@ -33

Re: Release process & rolling new releases

2014-11-23 Thread Justus Winter
Quoting Samuel Thibault (2014-11-23 21:11:05) > Hello, > > David Michael, le Wed 19 Nov 2014 19:39:43 -0500, a écrit : > > The only issue was that /etc/hurd/runsystem.hurd didn't get installed. > > I tacked the following onto patch #4 in the series to try it. > > Justus, do we need it? I guess i

Re: [PATCH] utils/mount: canonicalize mountpoints

2014-11-23 Thread Gabriele Giacone
On Fri, Nov 21, 2014 at 4:12 AM, Samuel Thibault wrote: > Could you try the patch I have just pushed? I believe it should be > doing the right thing. I confirm it fixes pathnames. Thanks -- G..e

Re: Release process & rolling new releases

2014-11-23 Thread Samuel Thibault
Hello, David Michael, le Wed 19 Nov 2014 19:39:43 -0500, a écrit : > The only issue was that /etc/hurd/runsystem.hurd didn't get installed. > I tacked the following onto patch #4 in the series to try it. Justus, do we need it? Samuel

Re: One-line build-test from busybox statically built segfaults on GNU/Hurd

2014-11-23 Thread Samuel Thibault
Samuel Thibault, le Sun 23 Nov 2014 19:48:15 +0100, a écrit : > It seems that on Linux the libc also gets dlopened like that, but I > guess initialization happens to get done enough for it to be working. Ok, I have found where to fix it, and will commit. Samuel

Re: One-line build-test from busybox statically built segfaults on GNU/Hurd

2014-11-23 Thread Samuel Thibault
Hello, Svante Signell, le Thu 20 Nov 2014 12:42:30 +0100, a écrit : > (11:03:58) mjt: hello. it looks like hurd-i386 is the only arch where my > one-line build-test program fails -- see > https://buildd.debian.org/status/package.php?p=busybox I've had a closer look. My initial guess was wrong.

Atomic file locking update

2014-11-23 Thread Samuel Thibault
Hello, While Svante is working on the record locking, I have worked on at least fixing whole file locking: there was one bug in our current implementation: flock(LOCK_SH); flock(LOCK_EX);, as per POSIX, does not guarantee an atomic upgrade from LOCK_SH to LOCK_EX. But fcntl(SETLK,F_RDLCK); fcntl(S

Re: [PATCH,Hurd] Fix deallocation after proc_getprocinfo call

2014-11-23 Thread Samuel Thibault
Joel Brobecker, le Sun 23 Nov 2014 13:56:29 +0400, a écrit : > The above does look unusual to me, but if it works and seems to be > the only correct way, let's go with that. It is a system interface actually, so we don't really have the choice :) Samuel

Re: [PATCHv2,Hurd] Fix deallocation after proc_getprocinfo call

2014-11-23 Thread Samuel Thibault
2014-10-02 Samuel Thibault * gdb/gnu-nat.c (inf_validate_procinfo): Multiply the number of elements pi_len by the size of the elements before calling vm_deallocate. (inf_validate_task_sc): Likewise, and properly deallocate the noise array. diff --git a/g

Re: Minimal Hurd Kernel Source Code

2014-11-23 Thread Richard Braun
On Sun, Nov 23, 2014 at 09:21:45AM +0100, Daniel wrote: > I am searching for a minimal edition of the Hurd Kernel > ( this is the right mailing list, isn't it? ) to transfere it to an > exotic platform, which is pretty small, too. > I am searching for something like an early development release >

Re: [PATCH,Hurd] Fix deallocation after proc_getprocinfo call

2014-11-23 Thread Joel Brobecker
> > > - vm_deallocate (mach_task_self (), (vm_address_t) pi, pi_len); > > > + vm_deallocate (mach_task_self (), (vm_address_t) pi, pi_len * > > > sizeof (*(procinfo_t) 0)); > > > > Suggest using "sizeof (struct procinfo)", which I think is better > > than dereferencing a NULL pointer. T

Re: [PATCH,Hurd] Fix deallocation after proc_getprocinfo call

2014-11-23 Thread Samuel Thibault
Joel Brobecker, le Sun 23 Nov 2014 11:44:52 +0400, a écrit : > > - vm_deallocate (mach_task_self (), (vm_address_t) pi, pi_len); > > + vm_deallocate (mach_task_self (), (vm_address_t) pi, pi_len * sizeof > > (*(procinfo_t) 0)); > > Suggest using "sizeof (struct procinfo)", which I think