Date: Wed, 7 Jun 2000 22:24:15 -0400 From: "Matthew Emmerton" <matt@gsicomp.on.ca> To: "Mark Newton" <newton@internode.com.au>, "Dan Nelson" <dnelson@emsphone.com> Cc: "Matthew Emmerton" <matt@xena.gsicomp.on.ca>, <freebsd-hackers@FreeBSD.ORG> Subject: Re: SVR4 Emulation [was Re: iBCS status?] Message-ID: <000a01bfd0f0$a760ca50$1200a8c0@matt> References: <000a01bfcf7a$cc810330$1200a8c0@matt> <20000606152128.B82736@internode.com.au> <20000606012552.A1515@dan.emsphone.com> <20000606162453.B83108@internode.com.au> <20000606094719.A19961@dan.emsphone.com> <006101bfd04c$59de5c60$1200a8c0@matt> <20000607094626.B22129@dan.emsphone.com> <20000608101038.B46114@internode.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
> To fix it in as painless a way as possible, I'm envisaging something > along the lines of this: > > * The existing svr4 KLD module, which implements the guts of the > emulator; and > > * Additional much, much smaller modules which implement the differences > between the "base" svr4 and wierd oddball variants. Modularity seems to be the most logical way to go. The ibcs2 stuff was sortof written like this (ibcs2.ko, and then ibcs2_coff.ko handled all the COFF-specific stuff; yes, it's quite different, but the concept was similar.) > Each variant would have its own ELF brand to aid the selection of the > correct API. Makes sense. On a related note, I'm curious to see how this will integrate into existing non-kernel tools. For example, truss and brandelf) only understand BSD and Linux ELF binaries, and will require modifications to identify all the different brands. What may compound the problem is if multiple ELF formats use the same brand, or none at all (as is the case with SCO ODT5 binaries.) -- Matthew Emmerton GSI Computer Services 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?000a01bfd0f0$a760ca50$1200a8c0>