From: gt8134b@prism.gatech.EDU (Howlin' Bob) Subject: Re: was Linux/SCO Date: 7 Aug 1993 18:39:32 GMT
In <1993Aug06.125143.14211@taylor.uucp> mark@taylor.uucp (Mark A. Davis) writes:
>>>I hope not.... I still think it is the only quick way to 1000's of
>>>commercial applications :( It could throw Linux into mainstream....
>>>Imagine, a Unix OS with LOTS of commercial apps compatible for $0
>> My understanding is that most commercial applications are currently
>>SVr3 (i.e. COFF, not ELF). Something to keep in mind...
>Correct. That was the highest on my wish list for Linux, COFF compatibility.
>ELF would be very nice, but most of the stuff I and other business users
>want to run is in COFF format (although some is available in ELF too).
Well, for compatibility reasons COFF would be nice, but I think the work
on ELF support has a "hidden" agenda: Eric is implementing the machinery
necessary for loading ELF-style executables and shared libraries. Once
the GNU tools are ready to produce ELF reliably, Linux might well
benefit from using ELF as a *native* executable format. ELF avoids problems
like address space cluttering by having the shared libraries loadable at
*any* address (well, they have to be 4k aligned to demand page well...),
different memory "heaps" like the unspecified mmap() and shared memory
attachments by placing mmap()ed files, shared memory, and libraries
on one big heap. ELF is also a more flexible dynamic linking scheme
than out current "DLL" scheme: Eric did what he could and still maintain
backwards compatibility, but it might be time to move on.
The upshot is that the ELF work could benefit even us Linux users who
own no other Intel UNIX applications. Not to leave COFF out: Eric
has implemented a flexible loading scheme that allows for multiple
exectuable formats to be recognized and loaded by the kernel (see
ALPHA-pl12). Executables are now loaded via Eric's read-only mmap()
implementation, as are shared libraries, so the demand paging code is
centralized and, in my opinion, much cleaner.
To really do it right, mmap() needs to be a little smarter about page
sharing files mmap()ed at different addresses, but that can all be
done with no changes to the executable loading code. It's a really
nice system; as usual, Eric and Linus have done a bangup job.
I imagine Eric has access to a SVR4 system, so ELF compatibility is
more important to him. Perhaps once the multiple-executable format
is stably in place, someone who works mainly on COFF-oriented
systems will implement COFF loading. It's still no easy job: you
have to implement a few rather sticky translation schemes, most
notably a lot of constants translations (like for IOCTL numbers).
You have to implement a COFF sharedlib -> Linux sharedlib interface,
or perhaps you could simply change the libc sources and recompile
to have a new COFF shared library. Also, I'm not sure what sort
of trap a statically linked COFF exectuable uses for syscalls:
I think it's "lcall 7,0", in which case you can just use the lcall
entry point Linus put in fairly recently for just this purpose.
However, then you need to do argument and syscall number translation
before the actual kernel syscall happens: having the lcall 7,0
do a callback to a translation program might be a good idea to
keep kernel bloat down, as well as to ease development.
So, Mark, are you up for a little kernel hacking :-) ?
--
Robert Sanders
Georgia Institute of Technology, Atlanta Georgia, 30332
uucp: ...!{decvax,hplabs,ncar,purdue,rutgers}!gatech!prism!gt8134b
Internet: gt8134b@prism.gatech.edu