Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id ; Thu, 14 Feb 2002 12:03:36 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id ; Thu, 14 Feb 2002 12:03:26 -0500 Received: from dell-paw-3.cambridge.redhat.com ([195.224.55.237]:64504 "HELO executor.cambridge.redhat.com") by vger.kernel.org with SMTP id ; Thu, 14 Feb 2002 12:03:16 -0500 To: Jeff Garzik Cc: David Howells , torvalds@transmeta.com, davidm@hpl.hp.com, "David S. Miller" , anton@samba.org, linux-kernel@vger.kernel.org, zippel@linux-m68k.org Subject: Re: [PATCH] move task_struct allocation to arch In-Reply-To: Message from Jeff Garzik of "Thu, 14 Feb 2002 11:46:13 EST." <3C6BE9D5.23D596A9@mandrakesoft.com> User-Agent: EMH/1.14.1 SEMI/1.14.3 (Ushinoya) FLIM/1.14.3 (=?ISO-8859-4?Q?Unebigory=F2mae?=) APEL/10.3 Emacs/21.1 (i386-redhat-linux-gnu) MULE/5.0 (SAKAKI) MIME-Version: 1.0 (generated by SEMI 1.14.3 - "Ushinoya") Content-Type: text/plain; charset=US-ASCII Date: Thu, 14 Feb 2002 17:03:14 +0000 Message-ID: <12214.1013706194@warthog.cambridge.redhat.com> From: David Howells Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Jeff Garzik 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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/