bug #15403 : can't mlock mmap'd memory

2006-01-17 Thread Samuel Thibault
Hi, It seems that the bug#15403[1] reply didn't get CCed to bug-hurd, so here it is: https://savannah.gnu.org/bugs/?func=detailitem&item_id=15403 === Some tests seem to show that only stacked objects can be mlock()ed. Mlock() is implemented through vm_wire(blabla, VM_PROT_ALL): `Specify that th

Re: [RFC] Fix setsid(0)

2006-01-17 Thread Thomas Bushnell BSG
Samuel Thibault <[EMAIL PROTECTED]> writes: > Thomas Bushnell BSG, le Tue 17 Jan 2006 13:56:05 -0800, a écrit : >> The same situation happens with getpgid, and you will see that in the >> case of getpgid, the C library handles the zero-argument case itself. > > Well, it is a bit different: I'd int

Re: [RFC] Fix setsid(0)

2006-01-17 Thread Samuel Thibault
Alfred M. Szmidt, le Tue 17 Jan 2006 23:55:11 +0100, a écrit : >The question might be rephrased into: do we want proc server >interaction to be XSI-compliant, or do we want strict XSI >compliancy only at libc level? > > glibc is the proper place, it should be XSI compliant. proc might

Re: [RFC] Fix setsid(0)

2006-01-17 Thread Alfred M\. Szmidt
The question might be rephrased into: do we want proc server interaction to be XSI-compliant, or do we want strict XSI compliancy only at libc level? glibc is the proper place, it should be XSI compliant. proc might not be though. ___ Bug-hur

Re: [RFC] Fix setsid(0)

2006-01-17 Thread Samuel Thibault
Hi, Thomas Bushnell BSG, le Tue 17 Jan 2006 13:56:05 -0800, a écrit : > The same situation happens with getpgid, and you will see that in the > case of getpgid, the C library handles the zero-argument case itself. Well, it is a bit different: I'd interpret the way the C library does it as an opti

Re: [RFC] Fix setsid(0)

2006-01-17 Thread Samuel Thibault
Hi, Thomas Bushnell BSG, le Tue 17 Jan 2006 11:41:15 -0800, a écrit : > This patch seems like the right idea. > > 1: You should remove the comment that CALLERP is ignored. > 2: CALLERP may be null if the RPC is received on the wrong kind of >port (in which case EOPNOTSUPP should be returned).

Re: [RFC] Fix setsid(0)

2006-01-17 Thread Thomas Bushnell BSG
I think your patch is ok, but I have thought more and think that it is the wrong place to make this change. The same situation happens with getpgid, and you will see that in the case of getpgid, the C library handles the zero-argument case itself. I believe that the same should be done here, for

Re: [RFC] Fix getsid(0)

2006-01-17 Thread Samuel Thibault
Thomas Bushnell BSG, le Tue 17 Jan 2006 11:33:48 -0800, a écrit : > > It's an XSI extension: > > > > « The getsid() function shall obtain the process group ID of the > > process that is the session leader of the process specified by pid. If > > pid is (pid_t)0, it specifies the calling process. » >

Re: [RFC] Fix setsid(0)

2006-01-17 Thread Thomas Bushnell BSG
Samuel Thibault <[EMAIL PROTECTED]> writes: > [hurd]/proc/Changelog > 2006-01-17 Samuel Thibault <[EMAIL PROTECTED]> > > Fix setsid(0). > > * pgrp.c (S_proc_getsid): When pid == 0, use `callerp' argument > instead of pid_find(pid). > > Index: pgrp.c > ==

Re: [RFC] Fix getsid(0)

2006-01-17 Thread Thomas Bushnell BSG
Samuel Thibault <[EMAIL PROTECTED]> writes: > Thomas Bushnell BSG, le Tue 17 Jan 2006 00:46:49 -0800, a écrit : >> Samuel Thibault <[EMAIL PROTECTED]> writes: >> >> > Currently, setsid(0) always return 1, while it should return the sid of >> > the calling process. Here is a proposed patch: >> >

Re: [RFC] Fix setsid(0)

2006-01-17 Thread Manuel Menal
Thomas Bushnell BSG wrote: Samuel Thibault <[EMAIL PROTECTED]> writes: Currently, setsid(0) always return 1, while it should return the sid of the calling process. Here is a proposed patch: I have no particular objection, but what is the standard that specifies its return value this way?

Re: [RFC] Fix setsid(0)

2006-01-17 Thread Marco Gerards
Thomas Bushnell BSG <[EMAIL PROTECTED]> writes: > Samuel Thibault <[EMAIL PROTECTED]> writes: > >> Currently, setsid(0) always return 1, while it should return the sid of >> the calling process. Here is a proposed patch: > > I have no particular objection, but what is the standard that > specifie

Re: [RFC] Fix setsid(0)

2006-01-17 Thread Manuel Menal
Thomas Bushnell BSG wrote: Samuel Thibault <[EMAIL PROTECTED]> writes: Currently, setsid(0) always return 1, while it should return the sid of the calling process. Here is a proposed patch: I have no particular objection, but what is the standard that specifies its return value this way?

Re: User TSS fixup

2006-01-17 Thread Marco Gerards
Samuel Thibault <[EMAIL PROTECTED]> writes: > [gnumach]/Changelog > 2006-01-14 Samuel Thibault <[EMAIL PROTECTED]> > > * i386/i386/iopb.c: Include "vm_param.h". > (io_tss_init): Fix address and limit of user TSS. What does this do? Thanks, Marco __

Re: [RFC] Fix setsid(0)

2006-01-17 Thread Thomas Bushnell BSG
Samuel Thibault <[EMAIL PROTECTED]> writes: > Currently, setsid(0) always return 1, while it should return the sid of > the calling process. Here is a proposed patch: I have no particular objection, but what is the standard that specifies its return value this way? Despite the suggestive name o