Date: Fri, 9 Jun 2000 09:38:58 +0930 From: Mark Newton <newton@internode.com.au> To: Dan Nelson <dnelson@emsphone.com> Cc: John Polstra <jdp@polstra.com>, hackers@FreeBSD.ORG Subject: Re: SVR4 Emulation [was Re: iBCS status?] Message-ID: <20000609093858.B50070@internode.com.au> In-Reply-To: <20000608120525.A183@dan.emsphone.com> References: <000a01bfcf7a$cc810330$1200a8c0@matt> <20000607094626.B22129@dan.emsphone.com> <20000608101038.B46114@internode.com.au> <20000607224010.A29029@dan.emsphone.com> <200006081617.JAA49089@vashon.polstra.com> <20000608120525.A183@dan.emsphone.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Thu, Jun 08, 2000 at 12:05:25PM -0500, Dan Nelson wrote:
> Is there any recommendations on how an OS should
> supply an SVR4 libc to an SVR4 application when the OS itself may not
> be SVR4-compliant?
That's what /compat/svr4 is for :-)
> Sounds like trying to emulate "SVR4" in itself isn't sufficient. We
> can still call the kld svr4.ko, but it's really doing SCO/SolarisX86
> syscall emulation.
It is possible to reimplement libc and any/every other library that a
SysV application would want, but that isn't happening at any time soon.
That means we really need to put the syscall mappings into the svr4.ko
module as we do at the moment, but perhaps put the syscall# -> syscall()
mappings into separate modules (solaris.ko, sco.ko, unixware.ko, etc).
- mark
--
Mark Newton Email: newton@internode.com.au (W)
Network Engineer Email: newton@atdot.dotat.org (H)
Internode Systems Pty Ltd Desk: +61-8-82232999
"Network Man" - Anagram of "Mark Newton" Mobile: +61-416-202-223
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20000609093858.B50070>