From: David Howells <dhowells@redhat.com>
To: Jeff Garzik <jgarzik@mandrakesoft.com>
Cc: David Howells <dhowells@redhat.com>,
torvalds@transmeta.com, davidm@hpl.hp.com,
"David S. Miller" <davem@redhat.com>,
anton@samba.org, linux-kernel@vger.kernel.org,
zippel@linux-m68k.org
Subject: Re: [PATCH] move task_struct allocation to arch
Date: Thu, 14 Feb 2002 17:03:14 +0000 [thread overview]
Message-ID: <12214.1013706194@warthog.cambridge.redhat.com> (raw)
In-Reply-To: Message from Jeff Garzik <jgarzik@mandrakesoft.com> of "Thu, 14 Feb 2002 11:46:13 EST." <3C6BE9D5.23D596A9@mandrakesoft.com>
Jeff Garzik <jgarzik@mandrakesoft.com> wrote:
> David Howells wrote:
> > > Is this the first in a multi-step patch series, or something like that?
> >
> > What makes you ask that?
>
> Because your patch just flat out duplicates code line for line into two
> arches.
What I do to it next depends on the feedback I get back.
> I am wondering where you want to go with this, short term and long
> term. Is the implementation of this on other arches gonna look the same
> -- just line for line copy of code? With maybe ia64 as the lone
> exception?
Ask Linus, he asked for the task_struct/thread_info split. Various people have
complained about the two things being allocated separately (maintainers for
m68k and ia64 archs certainly, and if I remember rightly, x86_64 as well,
though I don't appear to have saved the message for that). However, DaveM
(sparc64) appears to really be in favour of it.
In any case, this is just a corollary to my main aim of getting task ornaments
included in the kernel. The userspace resumption notification was the true
prerequisite, to support which I adjusted entry.S to make sure it didn't cost
any extra clock cycles. This led to Linus requesting that everything that
entry.S needs to access be separated out into another structure (so that
entry.S never accesses task_struct).
David
next prev parent reply other threads:[~2002-02-14 17:03 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2002-02-14 15:26 [PATCH] move task_struct allocation to arch David Howells
2002-02-14 16:13 ` Jeff Garzik
2002-02-14 16:32 ` David Howells
2002-02-14 16:46 ` Jeff Garzik
2002-02-14 17:03 ` David Howells [this message]
2002-02-14 20:48 ` Roman Zippel
2002-02-14 23:53 ` Richard Henderson
2002-02-15 9:56 ` Jeff Garzik
2002-02-15 10:01 ` Jeff Garzik
2002-02-15 11:25 ` Roman Zippel
2002-02-15 11:37 ` David Howells
2002-02-15 12:20 ` Roman Zippel
2002-02-15 12:56 ` David Howells
2002-02-15 13:49 ` Roman Zippel
2002-02-15 13:51 ` Jeff Garzik
2002-02-15 14:22 ` Roman Zippel
2002-02-15 14:07 ` David Howells
2002-02-15 14:28 ` Roman Zippel
2002-02-15 21:56 ` Richard Henderson
2002-02-15 21:52 ` Richard Henderson
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=12214.1013706194@warthog.cambridge.redhat.com \
--to=dhowells@redhat.com \
--cc=anton@samba.org \
--cc=davem@redhat.com \
--cc=davidm@hpl.hp.com \
--cc=jgarzik@mandrakesoft.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
--cc=zippel@linux-m68k.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