>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
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 <email@example.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message