From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: msnyder@redhat.com
Cc: mark.kettenis@xs4all.nl, gdb-patches@sources.redhat.com, drow@false.org
Subject: Re: [RFA] Linux Checkpoints, take 3
Date: Wed, 04 Jan 2006 19:16:00 -0000 [thread overview]
Message-ID: <200601041914.k04JEVdO003889@elgar.sibelius.xs4all.nl> (raw)
In-Reply-To: <43BB0E85.5050003@redhat.com> (message from Michael Snyder on Tue, 03 Jan 2006 15:53:41 -0800)
> Date: Tue, 03 Jan 2006 15:53:41 -0800
> From: Michael Snyder <msnyder@redhat.com>
>
> Mark Kettenis wrote:
>
> >
> >
> >>+ /* Now save the 'state' (file position) of all open file descriptors.
> >>+ Unfortunately fork does not take care of that for us... */
> >
> >
> > Hmm, fork(2) clones it file descroptors but both file descriptors
> > refer to the same open file description. Nasty. Wonder whether it'd
> > be possible to copy the open file descriptorions too. Well, I guess
> > the point was to do this without kernel support...
>
> This time around, anyway. I like the successive approximation approach.
> So much the better if, on the next pass, we can do even better by using
> kernel support.
>
> > Anyway, a few problems that I spotted:
> >
> > 1. Please drop the "extern" from _initialize_linux_fork() (and the
> > associated comment). You'll need an explicit prototype again, like:
> >
> > /* Prevent warning from -Wmissing-prototypes. */
> > void _initialize_linux_fork (void);
>
> I don't understand the motivation, but OK.
It's a while ago since we last discussed this, but we don't want
"extern" variable declarations in .c files; those should go into the
appropriate .h file. To make it easier to check whether we make any
mistakes (the ARI checks for this), it's easier to completely ban
"extern" from .c files
> > 5. Could you seperate out the "Detaching after fork from child
> > process" printing?
>
> Sorry, don't understand the request.
Bleah, I misread your diff; please ignore this.
>
> > And from the nitpicking department:
> >
> > 1. The comments on the #includes are a bit silly. I'd rather not see
> > any unless there's something really unobvious going on. They get
> > out of data pretty soon anyway.
>
> Ooooook, sure...
>
> > 2. Please don't put the function name in comments above the function.
> > (call_lseek, linux_fork_killall, linux_fork_mourn_inferior,
>
> 'k...
>
> > 3. Really sorry to hear that you're suffering from a split personality
> > problem:
> >
> >
> >>2005-12-19 Michael Snyder <msnyder@redhat.com>
> >>
> >>2005-12-19 Michael Van Meter Snyder <michsnyd@clwang-lnx.cisco.com>
>
> Well, that's life on the Information Superhighway...
>
> > Otherwise, I think it's ok. It's a bit sad that this is a Linux-only
> > implementation, but then it's mostly Linux-specific code.
>
> Well, it's intimately tied in with the linux follow-fork code.
> It should be possible to do something similar with other systems
> where follow-fork works -- but the only other one I'm aware of is
> hpux.
Heh, OpenBSD 3.9 will have follow-fork ;-).
Anyway, please go ahead and commit this.
Mark
next prev parent reply other threads:[~2006-01-04 19:16 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-12-24 16:32 Michael Snyder
2005-12-24 17:02 ` Eli Zaretskii
2005-12-26 18:58 ` Daniel Jacobowitz
2005-12-26 19:27 ` Eli Zaretskii
2005-12-27 15:38 ` Mark Kettenis
2005-12-27 15:40 ` Eli Zaretskii
2006-01-03 23:54 ` Michael Snyder
2006-01-04 19:16 ` Mark Kettenis [this message]
2006-01-04 19:36 ` Michael Snyder
2006-01-04 1:49 ` Michael Snyder
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200601041914.k04JEVdO003889@elgar.sibelius.xs4all.nl \
--to=mark.kettenis@xs4all.nl \
--cc=drow@false.org \
--cc=gdb-patches@sources.redhat.com \
--cc=msnyder@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox