From: Roland McGrath <roland@redhat.com>
To: OGAWA Hirofumi <hirofumi@mail.parknet.co.jp>
Cc: Linus Torvalds <torvalds@osdl.org>, 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 17:11:32 -0700 [thread overview]
Message-ID: <200409010011.i810BW5S001885@magilla.sf.frob.com> (raw)
In-Reply-To: OGAWA Hirofumi's message of Tuesday, 31 August 2004 22:19:04 +0900 <87k6vfqwc7.fsf@devron.myhome.or.jp>
> Should we also clean up and improve those with user-visible change?
> Those should be thought as separate issue?
The first answer to give is to the second question: yes, this is a
separate subject from the implementation changes we are discussing right
now. I don't really want to get into discussing a different interface at
the moment, because I have more than enough to do this week already.
It is certainly something I have considered. Cleaning up ptrace for use
on multi-threaded processes was no fun at all. Dan Jacobowitz and I have
talked about this before, and my tendency is the same he mentioned, to
start along the lines of the Solaris /proc interface. (However, I would
not make Solaris compatibility a priority over implementation sanity.)
But like I said, not for this week!
An important step to a sane and clean implementation of whatever new
interface will be to clean up the machine-specific parts of the
implementation that are required. If I am ever going to work on this
code again and not turn homicidal, it needs to take the form of a general
framework for special state examination/mutation requests machines
require uses common code to present these in whatever new interface and
compatibly for the ptrace requests that now exist. More for not this week.
I'd be happy to discuss details of all this stuff with anyone interested
in helping make it happen. But, you know, later.
Thanks,
Roland
next prev parent reply other threads:[~2004-09-01 0:14 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-08-31 3:25 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
2004-09-01 0:11 ` Roland McGrath [this message]
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
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=200409010011.i810BW5S001885@magilla.sf.frob.com \
--to=roland@redhat.com \
--cc=akpm@osdl.org \
--cc=hirofumi@mail.parknet.co.jp \
--cc=linux-kernel@vger.kernel.org \
--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
all inboxes | Powered by JetHome®