From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S261620AbTDHTgL (for ); Tue, 8 Apr 2003 15:36:11 -0400 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S261649AbTDHTgK (for ); Tue, 8 Apr 2003 15:36:10 -0400 Received: from almesberger.net ([63.105.73.239]:31241 "EHLO host.almesberger.net") by vger.kernel.org with ESMTP id S261620AbTDHTgJ (for ); Tue, 8 Apr 2003 15:36:09 -0400 Date: Tue, 8 Apr 2003 16:47:18 -0300 From: Werner Almesberger To: Paul Larson Cc: Andi Kleen , Robert Williamson , lkml , aniruddha.marathe@wipro.com, ltp-list@lists.sourceforge.net Subject: Re: [LTP] Re: Same syscall is defined to different numbers on 3 different archs(was Re: Makefile issue) Message-ID: <20030408164718.F18709@almesberger.net> References: <20030407232302.D19288@almesberger.net> <1049808651.30732.113.camel@plars> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1049808651.30732.113.camel@plars>; from plars@linuxtestproject.org on Tue, Apr 08, 2003 at 08:30:50AM -0500 Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org Paul Larson wrote: > I don't think so. Apps should be accessing things through libraries > anyway. The only reason we don't in some cases like this is that it's > new and not in libs on any distro yet. Well yes, if the syscall is correctly implemented in the library, there's no problem. > Besides, I don't think having a > /proc/syscalls would be any better than having to do ifdefs or use > kernel headers. #ifdef may be hard pressed to identify a specific kernel with a specific patch. Kernel headers are obviously a solution (although this violates the "user space must never include kernel headers" pseudo-rule), but add the problem of needing to identify the "current" source tree, which is a configuration step almost always requiring manual intervention. My suggestion for /proc/syscalls isn't entirely serious, but it would be nice if we could eventually solve this problem ... - Werner -- _________________________________________________________________________ / Werner Almesberger, Buenos Aires, Argentina wa@almesberger.net / /_http://www.almesberger.net/____________________________________________/