From owner-freebsd-hackers Tue Nov 17 06:39:01 1998 Return-Path: Received: (from majordom@localhost) by hub.freebsd.org (8.8.8/8.8.8) id GAA19852 for freebsd-hackers-outgoing; Tue, 17 Nov 1998 06:39:01 -0800 (PST) (envelope-from owner-freebsd-hackers@FreeBSD.ORG) Received: from www.scancall.no (www.scancall.no [195.139.183.5]) by hub.freebsd.org (8.8.8/8.8.8) with SMTP id GAA19847 for ; Tue, 17 Nov 1998 06:38:58 -0800 (PST) (envelope-from Marius.Bendiksen@scancall.no) Received: from super2.langesund.scancall.no [195.139.183.29] by www with smtp id KAWPQUOJ; Tue, 17 Nov 98 14:38:32 GMT (PowerWeb version 4.04r6) Message-Id: <3.0.5.32.19981117153828.0092dbe0@mail.scancall.no> X-Sender: Marius@mail.scancall.no X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.5 (32) Date: Tue, 17 Nov 1998 15:38:28 +0100 To: Robert Nordier From: Marius Bendiksen Subject: Re: FreeBSD on i386 memory model Cc: freebsd-hackers@FreeBSD.ORG In-Reply-To: <199811171338.PAA10216@ceia.nordier.com> References: <3.0.5.32.19981117125202.00916bb0@mail.scancall.no> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Sender: owner-freebsd-hackers@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.ORG >Yes, flow of control is all though a central point, so the sky's >probably the limit. If you want to produce a system which won't run Indeed. Compare with OS/2, which has 4 or 5 different calling conventions, plus a couple which only the IBM compilers use. >standard binaries, for instance (which may be handy for security >reasons), it would be fairly trivial here. Let's not get into a debate over the 'security through obscurity' philosophy here. :) >I guess it mostly depends on context and personal preference. The i386 Probably. I prefer call gates, though. >with interrupt/trap gates anyway, so it can simplify the support code >considerably, if you deal only with those. Depends on the basic syscall mechanism, doesn't it? >In the case of FreeBSD, the lcall actually does result in some register >juggling in order to produce a trap frame; so maybe this bears out >the above philosophy. As I said, I've not looked closer at this code, so I'm not familiar with how this is done. >Things are certainly heading in that direction. And for a fairly good reason :) >I doubt there's any win in changing the syscall interface at this *nod* The syscall interface is probably just fine as it is. I was only stating that if, for some reason, the work had to be done, I'd consider working on it. >stage; but moving initialization code is a potential project. Of >course there are potentially massive inertia, compatibility and other >non-technical problems associated with this. :-) Any volunteers? Objections? Ideas about the scale of such an effort? An idea of the impact it might have? >Well, both Linux and NetBSD apparently use the int 0x80 approach; but I >should think the basic mechanism is most likely a fairly small part of >the complete picture. In most emulation, semantics rather than syntax >tends to be where things get tricky. Yup. Hmm; using call gates for the BSD calls, and int 0x80 for the emulation calls might be good for the compatlinux project's health, but, hey, I'm shooting in the dark here. --- Marius Bendiksen, IT-Trainee, ScanCall AS To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message