Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1760302AbYGCHG3 (ORCPT ); Thu, 3 Jul 2008 03:06:29 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1754337AbYGCG5h (ORCPT ); Thu, 3 Jul 2008 02:57:37 -0400 Received: from smtp1.linux-foundation.org ([140.211.169.13]:34042 "EHLO smtp1.linux-foundation.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753554AbYGCCfT (ORCPT ); Wed, 2 Jul 2008 22:35:19 -0400 Date: Wed, 2 Jul 2008 19:35:11 -0700 (PDT) From: Linus Torvalds To: Vitaly Mayatskikh cc: Andi Kleen , linux-kernel@vger.kernel.org, Andrew Morton Subject: Re: [PATCH 1/2] Introduce copy_user_handle_tail routine In-Reply-To: Message-ID: References: <486B8B6C.2050109@firstfloor.org> User-Agent: Alpine 1.10 (LFD 962 2008-03-14) MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1112 Lines: 33 On Wed, 2 Jul 2008, Vitaly Mayatskikh wrote: > > Linus wanted this routine to be extremely dumb. Well, I wanted it simple and dumb, but not dumber than _necessary_. I think if (cleartail) memset(dst,0,len); return len; is basically what we should have at the end. Simple and sweet. Now, the stuff that comes *before* that point is the "try to fix up one byte at a time" thing, which I'd like to be simple and dumb. At least to start with. Of course, I also suspect that *eventually* we might want to make it smarter and more complex. For example, while performance isn't a primary issue, we might want to eventually avoid having to do _two_ faults (once in the fast unrolled or word-at-a-time loop, and once in the byte-for-byte one), by limiting the byte-for-byte one to be within a page, but that would be a "future enhancement" thing. Linus -- 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/