Date: Thu, 8 Jun 2000 12:05:25 -0500 From: Dan Nelson <dnelson@emsphone.com> To: John Polstra <jdp@polstra.com> Cc: hackers@freebsd.org Subject: Re: SVR4 Emulation [was Re: iBCS status?] Message-ID: <20000608120525.A183@dan.emsphone.com> In-Reply-To: <200006081617.JAA49089@vashon.polstra.com>; from "John Polstra" on Thu Jun 8 09:17:18 GMT 2000 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>
next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (Jun 08), John Polstra said: > > But isn't there some SVR4 ABI standard that says "you must implement > > these syscalls and these ioctls this way", etc? I'm sure the ABI > > explicitly says what lseek() takes for arguments, for example. > > The SVR4 ABI specification doesn't say anything about system calls -- > it just specifies what libc has to provide. (Actually in my old > printed copy of the spec, they call the system interface library > "libsys".) The library has to provide a certain kind of lseek(), for > example, but the ABI standard says nothing about how that is > implemented lower down. Hmm. So does this mean that SVR4-compliant programs must be dynamically-linked? 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? And this doesn't address any libraries other than libc, I suppose? 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. -- Dan Nelson dnelson@emsphone.com 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?20000608120525.A183>