Hello,
This was posted to freebsd-questions with no reply.
I tried this and the child process created a core file.
I also tried the other options and they seem to work.
Just RFPROC and RFMEM DON'T!
Thanks,
Michael Mercer
Can any one suggest how to use rfork( R
Michael E. Mercer said:
> Hello,
>
> This was posted to freebsd-questions with no reply.
> I tried this and the child process created a core file.
> I also tried the other options and they seem to work.
> Just RFPROC and RFMEM DON'T!
>
rfork(RFMEM) doesn't easily w
> I tried this and the child process created a core file.
> > I also tried the other options and they seem to work.
> > Just RFPROC and RFMEM DON'T!
> >
> rfork(RFMEM) doesn't easily work from C. You need to
> create an assembly stub.
>
> --
> Joh
.
> > Just RFPROC and RFMEM DON'T!
> >
> rfork(RFMEM) doesn't easily work from C. You need to
> create an assembly stub.
>
> --
> John | Never try to teach a pig to sing,
> dy...@iquest.net | it makes one look stupid
> jdy...@nc.com
ther options and they seem to work.
> > > Just RFPROC and RFMEM DON'T!
> > >
> > rfork(RFMEM) doesn't easily work from C. You need to
> > create an assembly stub.
> >
> > --
> > John | Never try to teach a pig
core file.
> > > I also tried the other options and they seem to work.
> > > Just RFPROC and RFMEM DON'T!
> > >
> > rfork(RFMEM) doesn't easily work from C. You need to
> > create an assembly stub.
> >
> > --
> > John
:> > rfork(RFMEM) doesn't easily work from C. You need to
:> > create an assembly stub.
:> >
:> > --
:> > John | Never try to teach a pig to sing,
:> > dy...@iquest.net | it makes one look stupid
:> > jdy...@nc.com
.globl ffork
.text
/*
* ffork(func, data, stack, stackSize)
*/
ffork:
/*
* Setup stack frame for new stack and store in register
* which will not be destroyed by call to rfork, %ebx.
*
* newsp -> func
*
On Sat, 20 Mar 1999, Matthew Dillon wrote:
>
> :> > rfork(RFMEM) doesn't easily work from C. You need to
> :> > create an assembly stub.
> :> >
> :> > --
> :> > John | Never try to teach a pig to sing,
> :> &g
ads.tar.gz contains an
implementation of a linux clone call using rfork. An alternative assembly
language interface to rfork, originally posted to -hackers by John Dyson
last summer, is attached. This was part of a larger posting of some kthread
code. Check the mail archives for the complete postin
completely share the address space, which
> RFMEM does, you can't split anything, not even the stack. It
> sure would be useful if there were a standard clib call adequate
> for calling rfork() and calling a function in the child w/ a new
> stack.
Possibilities fo
assed.
Why don't we simply implement the linux clone()? It sounds to me that
it would be trivial.
:the assembly wouldn't be needed. Hmm... actually... if one were to mmap() a
:stack and as soon as the rfork() returned movl newstack,%esp and whatnot,
:wouldn't this be a pr
I think Richard Seaman has it right: the stack needs to be passed.
>
> Why don't we simply implement the linux clone()? It sounds to me that
> it would be trivial.
Let's add another parameter to fork1/rfork():
pid_trfork __P((int, ...)); for userland
struc
:> :the assembly wouldn't be needed. Hmm... actually... if one were to mmap() a
:> :stack and as soon as the rfork() returned movl newstack,%esp and whatnot,
:> :wouldn't this be a pretty simple solution?
:>
:> No, because one of the processes may overrun t
On Sun, 21 Mar 1999, Matthew Dillon wrote:
> :> :the assembly wouldn't be needed. Hmm... actually... if one were to mmap()
> a
> :> :stack and as soon as the rfork() returned movl newstack,%esp and whatnot,
> :> :wouldn't this be a pretty simple solution?
> :
:> If you are making a subroutine *call* to the rfork() routine, where
:> do you think the return PC address is stored? On the stack. The
:> rfork() routine is going to 'ret' *after* doing the rfork syscall.
:> 'ret' pops the stack. While thi
On Sun, 21 Mar 1999, Matthew Dillon wrote:
> :> If you are making a subroutine *call* to the rfork() routine, where
> :> do you think the return PC address is stored? On the stack. The
> :> rfork() routine is going to 'ret' *after* doing the rfork sysc
Seaman has it right: the stack needs to be passed.
>
> Why don't we simply implement the linux clone()? It sounds to me that
> it would be trivial.
Doing clone() in libc that calls rfork(2) and doing all the stack setup
should be pretty easy.. (Richard has done it alre
:> :proc B returns since proc B is going to immediately switch over to a new
:> :stack?
:>
:> The return address for the procedure call is on the stack. If something
:> munges the stack after the physical rfork occurs but before both
processes
:> can return fro
On Sun, 21 Mar 1999, Matthew Dillon wrote:
> :> :proc B returns since proc B is going to immediately switch over to a new
> :> :stack?
> :>
> :> The return address for the procedure call is on the stack. If
> something
> :> munges the stack after the
tly simplify things so all
> > of
> >
> > I think Richard Seaman has it right: the stack needs to be passed.
> >
> > Why don't we simply implement the linux clone()? It sounds to me that
> > it would be trivial.
>
> Doing clone() in
On Mon, Mar 22, 1999 at 11:34:25AM +0800, Peter Wemm wrote:
> Doing clone() in libc that calls rfork(2) and doing all the stack setup
> should be pretty easy.. (Richard has done it already, yes?)
Its in package at http://lt.tar.com/linuxthreads.tar.gz . If anyone wants
to grab it out of
On Mon, 22 Mar 1999, Richard Seaman, Jr. wrote:
> On Mon, Mar 22, 1999 at 11:34:25AM +0800, Peter Wemm wrote:
>
> > Doing clone() in libc that calls rfork(2) and doing all the stack setup
> > should be pretty easy.. (Richard has done it already, yes?)
>
> Its in pack
The Rfork man page says:
RFMEM If set, the kernel will force sharing of the entire ad-
dress space. The child will then inherit all the shared
segments the parent process owns. Other segment types
will be unaffected. Subsequent forks by the parent
I don't know is this is of any interest, but a rfork(0) will cause a
fault. I have included a patch.
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc015ff46
stack pointer = 0x10:0xc6894f38
frame pointer = 0x10:0xc6894f4c
code segment = bas
Yes, you are absolutely right.
It should also say: rfork() cannot be directly called from C when used
with RFMEM, because C cannot deal with the fact that both processes
return to the same stack.
( As an aside, we really need a linunx clone()-like system call so we
Peter Holm wrote:
> I don't know is this is of any interest, but a rfork(0) will cause a
> fault. I have included a patch.
Argh!
Thanks, Committed.. (rev 1.63 kern_fork.c)
Cheers,
-Peter
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current&quo
>db> p %eax
>c015ff46 <--- why this? eax == 0x8 in show reg
%eax seems to be an undetected syntax error. '%' seems to be an alias
for '.'. The %eax register is given by $eax.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
On Mon, Jul 11, 2011 at 03:27:56PM +0200, Petr Salinger wrote:
> >>This patch made by Petr Salinger improves compatibility with
> >>LinuxThreads in rfork() syscall. The Linux clone() implementation
> >>allows specifying the signal sent to parent when child termina
mething, only to
exclude some functionality, like syscall.
>
> We do not use SIGUSR1 currently, the eglibc side can detect whether
> it runs under new-enough kernel and decide whether use 0 or SIGCHLD
> for "no signal".
>
> The kernel side would be something like:
>
> if (flags & RFLINUXTHPN)
> {
> p2->p_sigparent = RFTHPNSIGNUM(flags);
> #if COMPAT8
> if (p2->p_sigparent == SIGCHLD)
>p2->p_sigparent = 0;
> #endif
> }
No, this is even uglier, and see the note about compat.
BTW, it seems that our rfork(2) ignores unknown flags. This should be
fixed, might be in the same patch.
pgpKtoNEs5oCP.pgp
Description: PGP signature
On Mon, Jul 11, 2011 at 04:50:44PM +0200, Petr Salinger wrote:
> >RFLINUXPTH was used by the linuxthreads port, that was popular in the
> >time of FreeBSD 4.x and may be 5.x to run mysql. I will object against
> >this breakage.
>
> Do I understand correctly that API/ABI backward compatibility with
2011/7/11 Kostik Belousov :
> I shall state that the sig == SIGCHLD case is ugly. Having the separate
> flag "do not send signal to the parent" would be much less clumsy.
> What are the requirements for the ABI stability for Debian/kFreeBSD ?
> Can this be fixed now, or is it too late ?
Perhaps we
RFLINUXPTH was used by the linuxthreads port, that was popular in the
time of FreeBSD 4.x and may be 5.x to run mysql. I will object against
this breakage.
Do I understand correctly that API/ABI backward compatibility with
previous FreeBSD releases w.r.t RFLINUXPTH is needed ?
The 1st patch s
Can you, please, describe the reasoning behind the
+ if (sig == SIGCHLD) sig = 0;
line ?
The main reason is backward compatibility.
The original FreeBSD code allows only to select between
SIGUSR1 or SIGCHLD signals.
The our extension changes meaning of RFLINUXTHPN to select sign
The 1st patch satisfies this. I agree that SIGCHLD part
is not easily readable.
The SIGCHLD part is ugly. This is why I am asking about possible ways
to overcome this.
We need a way to specify "no signal".
It can be "new flag" or "ugly SIGCHLD".
new flag:
pros: cleaner design
cons: one bit
On Mon, Jul 11, 2011 at 05:43:23PM +0200, Petr Salinger wrote:
> >>The 1st patch satisfies this. I agree that SIGCHLD part
> >>is not easily readable.
> >The SIGCHLD part is ugly. This is why I am asking about possible ways
> >to overcome this.
>
> We need a way to specify "no signal".
> It can be
I would instead use a new flag to specify a signal sent on the child
death. Like RFTSIGZMB. If flag is not set, SIGCHLD is used. If it is
set, the bit slice is used as signal number, 0 means do not send any
signal.
Please note that the signal should be checked for validity, it must be
<= _SIG_MAX
On Mon, Jul 11, 2011 at 06:12:15PM +0200, Petr Salinger wrote:
> >I would instead use a new flag to specify a signal sent on the child
> >death. Like RFTSIGZMB. If flag is not set, SIGCHLD is used. If it is
> >set, the bit slice is used as signal number, 0 means do not send any
> >signal.
> >
> >Pl
terface we
should use.
So far defined rfork() options:
/*
* XXX currently, some operations without RFPROC set are not supported.
*/
#define RFNAMEG (1<<0)/* UNIMPL new plan9 `name space' */
#define RFENVG (1<<1)/* UNIMPL copy plan9 `env space'
he version in brandnote is compile-time minimal supported version,
> we will detect at runtime (by "sysctl kern.osreldate") which interface we
> should use.
>
>
> So far defined rfork() options:
>
> /*
> * XXX currently, some operations without RFPROC set ar
On Tue, Jul 12, 2011 at 11:16:28AM +0200, Petr Salinger wrote:
> >>Seems this interface be acceptable ?
> >
> >Looks good to me.
>
> The proposed code changes are in the attached patch.
>
> Proposed wording of addition into RFORK(2):
Below is the patch I intend
Seems this interface be acceptable ?
Looks good to me.
The proposed code changes are in the attached patch.
Proposed wording of addition into RFORK(2):
DESCRIPTION:
RFTSIGZMB If set, the kernel will return selected signal number instead
of SIGCHILD upon thread exit
Below is the patch I intend to commit after you retest it.
I applied it against our 8.2 based package,
altered our "clone" to use this new
interface and run eglibc testsuite. No regression.
Our runtime detection of this new interface will be based
on "sysctl kern.osreldate".
some rewording
On Tue, Jul 12, 2011 at 04:36:24PM +0200, Petr Salinger wrote:
> >Below is the patch I intend to commit after you retest it.
>
> I applied it against our 8.2 based package,
> altered our "clone" to use this new
> interface and run eglibc testsuite. No regression.
>
> Our runtime detection of thi
2011/7/12 Kostik Belousov :
> I just committed this to HEAD. Will MFC in a week, unless some problems
> arise.
Thanks!
> I will bump revision for stable/8 when merging, but I do not see much
> reason to bump on HEAD right now.
Uhm I think we can survive without a bump in HEAD. For now we will
n
I will bump revision for stable/8 when merging, but I do not see much
reason to bump on HEAD right now.
Many thanks.
Uhm I think we can survive without a bump in HEAD. For now we will
need to keep our backward-compatibility patch anyway, and when the
bump happens on stable/8 our sysctl compar
On Tue, Jul 12, 2011 at 11:53:05PM +0200, Petr Salinger wrote:
> >>I will bump revision for stable/8 when merging, but I do not see much
> >>reason to bump on HEAD right now.
>
> Many thanks.
>
> >Uhm I think we can survive without a bump in HEAD. For now we will
> >need to keep our backward-com
http://www.freebsd.org/cgi/query-pr.cgi?pr=180976
Thank you,
Yuri
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
On Wed, Jul 31, 2013 at 11:24:31AM -0700, Yuri wrote:
> http://www.freebsd.org/cgi/query-pr.cgi?pr=180976
I've committed a modified version of the patch as r253850. Thanks!
-Mark
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mail
49 matches
Mail list logo
