From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from moutng.kundenserver.de ([212.227.126.187]:11747 "EHLO moutng.kundenserver.de") by vger.kernel.org with ESMTP id S932469AbWH1Hok convert rfc822-to-8bit (ORCPT ); Mon, 28 Aug 2006 03:44:40 -0400 From: Arnd Bergmann Subject: Re: [PATCH 2/7] rename the provided execve functions to kernel_execve Date: Mon, 28 Aug 2006 09:44:21 +0200 References: <20060827214734.252316000@klappe.arndb.de> <20060827215636.091665000@klappe.arndb.de> <20060827192030.633cf467.rdunlap@xenotime.net> In-Reply-To: <20060827192030.633cf467.rdunlap@xenotime.net> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8BIT Content-Disposition: inline Message-Id: <200608280944.21819.arnd@arndb.de> Sender: linux-arch-owner@vger.kernel.org To: "Randy.Dunlap" Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org, Jeff Dike , Bjoern Steinbrink , Arjan van de Ven , Chase Venters , Andrew Morton , Russell King , rusty@rustcorp.com.au List-ID: On Monday 28 August 2006 04:20, Randy.Dunlap wrote: > Question: > All other syscalls (in syscalls.h) return long or unsigned long > or ssize_t etc.  I.e., none of them return int.  Does this one > return int because it's strictly an inside-the-kernel "syscall", > not exposed to userspace? Well, it's not really a system call in the first place, but I could not find any other place where it would fit. The prototype of the kernel_execve function is the one from the man execve page, and also similar to those that were generated by the _syscall3() macro before. Arnd <><