> 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 [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
