From: Daniel Jacobowitz <dan@debian.org>
To: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Cc: Linus Torvalds <torvalds@osdl.org>,
Roland McGrath <roland@redhat.com>, Andrew Morton <akpm@osdl.org>,
Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [PATCH] cleanup ptrace stops and remove notify_parent
Date: Tue, 31 Aug 2004 09:56:54 -0400 [thread overview]
Message-ID: <20040831135654.GA22337@nevyn.them.org> (raw)
In-Reply-To: <87k6vfqwc7.fsf@devron.myhome.or.jp>
On Tue, Aug 31, 2004 at 10:19:04PM +0900, OGAWA Hirofumi wrote:
> Linus Torvalds <torvalds@osdl.org> writes:
>
> > Ok, I definitely agree with the approach
>
> I agree with that approach.
>
> > Looks pretty clean as an implementation. The question is whether we should
> > aim for 2.6.9 or 2.6.10 - if the first, then I should probably take it
> > now, otherwise it should go into -mm first and be merged early after 2.6.9
> > has been released, for the first -rc.
> >
> > I _looks_ pretty safe, and it's hopefully much less likely to have subtle
> > bugs and races than our old approach had, but I have a hard time judging.
>
> Ptrace has several ugly things. And I'm thinking those needs
> user-visible change more or less to improve, like this.
> (->parent/wait4/child_list, PTRACE_SYSCALL/PTRACE_SINGLESTEP ...)
>
> Should we also clean up and improve those with user-visible change?
> Those should be thought as separate issue?
>
> I think we should be improved with new interface... (after it, we
> can deprecate ptrace)
I recommend the same thing I recommend every time this comes up: make
sure to take a look at how Solaris does this through /proc. It seems
to be much nicer.
--
Daniel Jacobowitz
next prev parent reply other threads:[~2004-08-31 13:57 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-31 3:25 [PATCH] cleanup ptrace stops and remove notify_parent Roland McGrath
2004-08-31 3:43 ` Andrew Morton
2004-08-31 4:11 ` Roland McGrath
2004-08-31 4:26 ` Andrew Morton
2004-08-31 5:43 ` Roland McGrath
2004-08-31 4:27 ` Linus Torvalds
2004-08-31 4:50 ` Roland McGrath
2004-08-31 13:19 ` OGAWA Hirofumi
2004-08-31 13:56 ` Daniel Jacobowitz [this message]
2004-09-01 0:11 ` Roland McGrath
2004-09-01 4:25 ` OGAWA Hirofumi
2004-08-31 9:29 ` Christoph Hellwig
2004-08-31 9:43 ` Anton Blanchard
2004-09-01 0:00 ` Roland McGrath
2004-08-31 3:59 ` Roland McGrath
2004-08-31 4:22 ` Daniel Jacobowitz
2004-08-31 4:55 ` Roland McGrath
2004-08-31 4:59 ` Daniel Jacobowitz
[not found] <2z7vs-2F1-13@gated-at.bofh.it>
2004-08-31 10:00 ` Andi Kleen
2004-09-01 0:27 ` Roland McGrath
2004-09-01 1:56 ` Roland McGrath
2004-09-04 13:38 ` Andi Kleen
-- strict thread matches above, loose matches on Subject: below --
2004-08-31 15:59 Albert Cahalan
2004-08-31 23:54 ` Roland McGrath
2004-09-01 0:27 ` Linus Torvalds
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=20040831135654.GA22337@nevyn.them.org \
--to=dan@debian.org \
--cc=akpm@osdl.org \
--cc=hirofumi@mail.parknet.co.jp \
--cc=linux-kernel@vger.kernel.org \
--cc=roland@redhat.com \
--cc=torvalds@osdl.org \
/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