From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22329 invoked by alias); 23 Jan 2006 15:57:12 -0000 Received: (qmail 22318 invoked by uid 22791); 23 Jan 2006 15:57:12 -0000 X-Spam-Check-By: sourceware.org Received: from cam-admin0.cambridge.arm.com (HELO cam-admin0.cambridge.arm.com) (193.131.176.58) by sourceware.org (qpsmtpd/0.31) with ESMTP; Mon, 23 Jan 2006 15:57:10 +0000 Received: from cam-owa1.Emea.Arm.com (cam-owa1.emea.arm.com [10.1.255.62]) by cam-admin0.cambridge.arm.com (8.12.6/8.12.6) with ESMTP id k0NFuS6s022952; Mon, 23 Jan 2006 15:56:28 GMT Received: from pc960.cambridge.arm.com ([10.1.255.211]) by cam-owa1.Emea.Arm.com with Microsoft SMTPSVC(6.0.3790.0); Mon, 23 Jan 2006 15:56:27 +0000 Subject: Re: sim/arm RedBoot meminfo syscall [PATCH] From: Richard Earnshaw To: Daniel Jacobowitz Cc: Shaun Jackman , gdb-patches@sources.redhat.com In-Reply-To: <20060123020134.GL27224@nevyn.them.org> References: <7f45d9390512141040m6d43725ag@mail.gmail.com> <20060123020134.GL27224@nevyn.them.org> Content-Type: text/plain Message-Id: <1138031768.1864.107.camel@pc960.cambridge.arm.com> Mime-Version: 1.0 Date: Mon, 23 Jan 2006 15:57:00 -0000 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-01/txt/msg00327.txt.bz2 On Mon, 2006-01-23 at 02:01, Daniel Jacobowitz wrote: > On Wed, Dec 14, 2005 at 11:40:28AM -0700, Shaun Jackman wrote: > > This patch implements the RedBoot meminfo syscall. In addition, rather > > than ignoring unhandled syscalls, it sets errno to ENOSYS and returns > > -1. This makes it possible to run "Hello, world!" compiled using > > newlib and a RedBoot libgloss. > > > > Cheers, > > Shaun > > > > 2005-12-14 Shaun Jackman > > > > * sim/arm/armos.c (ARMul_OSHandleSWI): Handle the RedBoot system > > call meminfo. Return ENOSYS for unhandled RedBoot syscalls. > > This looks totally plausible to me but I don't know much about it; > Richard, any opinion on it before I approve it? I've no objections. The SWI code has already been grabbed, so it doesn't really extend the interface any further. As a general principle, however, I'd be against adding more 'top-level' swi codes without cleaning up the interface to this module so that you can carefully select from the command line the set of SWIs in force. R.