Newsgroups: comp.os.linux
Path: gmd.de!newsserver.jvnc.net!howland.reston.ans.net!noc.near.net!
uunet!psinntp!newstand.syr.edu!rodan.acs.syr.EDU!cgbobbis
From: cgbob...@rodan.acs.syr.EDU (Shmoo)
Subject: Linux/SCO
Message-ID: <1993Jul25.140811.17650@newstand.syr.edu>
Organization: Syracuse University, Syracuse, NY
Date: Sun, 25 Jul 93 14:08:11 EDT
Lines: 4
With all of this asking about running SCO binaries on Linux, what about
the other way around? Would it be possible to us the Linux C comiler
somehow on and SCO System V system?
Newsgroups: comp.os.linux
Path: gmd.de!Germany.EU.net!news.dfn.de!darwin.sura.net!haven.umd.edu!
uunet!wyvern!taylor.wyvern.com!mark
From: m...@taylor.uucp (Mark A. Davis)
Subject: Re: Linux/SCO
Organization: Lake Taylor Hospital Computer Services
Date: Mon, 26 Jul 1993 04:04:37 GMT
Message-ID: <1993Jul26.040437.1691@taylor.uucp>
References: <1993Jul25.140811.17650@newstand.syr.edu>
Lines: 14
cgbob...@rodan.acs.syr.EDU (Shmoo) writes:
>With all of this asking about running SCO binaries on Linux, what about
>the other way around? Would it be possible to us the Linux C comiler
>somehow on and SCO System V system?
But why would you want to do that??? The only reason people want SCO
compatibility under Linux is for commercial applications.... There is
no application under Linux that can't be had for SCO Unix.
--
/--------------------------------------------------------------------------\
| Mark A. Davis | Lake Taylor Hospital | Norfolk, VA (804)-461-5001x431 |
| Sys.Administrator| Computer Services | m...@taylor.wyvern.com .uucp |
\--------------------------------------------------------------------------/
Newsgroups: comp.os.linux
Path: gmd.de!xlink.net!news.dfn.de!news.dkrz.de!ifmsun8.ifm.uni-hamburg.de!
lutzifer!wavehh.hanse.de!wolfhh!desaster!michaelw
From: micha...@desaster.hanse.de (Michael Will)
Subject: Re: Linux/SCO
References: <1993Jul25.140811.17650@newstand.syr.edu>
<1993Jul26.040437.1691@taylor.uucp>
Organization: Vogon Headquarter
Date: Wed, 28 Jul 1993 01:57:19 GMT
Message-ID: <1993Jul28.015719.13103@desaster.hanse.de>
Lines: 24
m...@taylor.uucp (Mark A. Davis) writes:
>But why would you want to do that??? The only reason people want SCO
>compatibility under Linux is for commercial applications.... There is
>no application under Linux that can't be had for SCO Unix.
Oh yes, there is:
ObjectBuilder from ParcPlace is free for Linux but would cost a great deal
of money if you would have to buy it for SCO :-)
At least for the HP they advertised $3000 and rising...
But I do not think they would like this idea :-) don't panic, it was very
hypotetical, I doubt it to become real :-)
The other way round, elf-binaries for Linux, was tackled by some guys on
the net, but then they seemed to fade away...?
Cheers, Michael Will
--
Michael Will <micha...@desaster.hanse.de> Linux - share and enjoy :-)
Life is not there if you can't share it... Hazel'O'Connor Breaking Glass
Happily using Linux 0.99p10 with X11R5, \LaTeX, cnews/nn/uucp and: PGP!
>>> Ask for Linux and / or pgp-Information <<<
Newsgroups: comp.os.linux
Path: gmd.de!xlink.net!howland.reston.ans.net!noc.near.net!uunet!wyvern!
taylor.wyvern.com!mark
From: m...@taylor.uucp (Mark A. Davis)
Subject: Re: Linux/SCO
Organization: Lake Taylor Hospital Computer Services
Date: Wed, 28 Jul 1993 18:12:23 GMT
Message-ID: <1993Jul28.181223.11097@taylor.uucp>
References: <1993Jul25.140811.17650@newstand.syr.edu>
<1993Jul26.040437.1691@taylor.uucp> <1993Jul28.015719.13103@desaster.hanse.de>
Lines: 25
micha...@desaster.hanse.de (Michael Will) writes:
>m...@taylor.uucp (Mark A. Davis) writes:
>>But why would you want to do that??? The only reason people want SCO
>>compatibility under Linux is for commercial applications.... There is
>>no application under Linux that can't be had for SCO Unix.
>Oh yes, there is:
>ObjectBuilder from ParcPlace is free for Linux but would cost a great deal
>of money if you would have to buy it for SCO :-)
Ok, so I'll count 1.
>The other way round, elf-binaries for Linux, was tackled by some guys on
>the net, but then they seemed to fade away...?
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
--
/--------------------------------------------------------------------------\
| Mark A. Davis | Lake Taylor Hospital | Norfolk, VA (804)-461-5001x431 |
| Sys.Administrator| Computer Services | m...@taylor.wyvern.com .uucp |
\--------------------------------------------------------------------------/
Newsgroups: comp.os.linux
Path: gmd.de!xlink.net!sol.ctr.columbia.edu!math.ohio-state.edu!
darwin.sura.net!ra!tantalus.nrl.navy.mil!eric
From: e...@tantalus.nrl.navy.mil (Eric Youngdale)
Subject: Re: Linux/SCO
Message-ID: <CBB3pv.KG8@ra.nrl.navy.mil>
Sender: use...@ra.nrl.navy.mil
Organization: Naval Research Laboratory
References: <1993Jul26.040437.1691@taylor.uucp>
<1993Jul28.015719.13103@desaster.hanse.de> <1993Jul28.181223.11097@taylor.uucp>
Date: Thu, 5 Aug 1993 21:58:42 GMT
Lines: 20
In article <1993Jul28.181223.11...@taylor.uucp> m...@taylor.uucp (Mark A. Davis)
writes:
>>The other way round, elf-binaries for Linux, was tackled by some guys on
>>the net, but then they seemed to fade away...?
No, I am still here. I have been working on merging the various
required patches with the distribution kernel a bit at a time. There was quite
a bit, but we are getting quite close...
>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...
-Eric
--
"When Gregor Samsa woke up one morning from unsettling dreams, he
found himself changed in his bed into a lawyer."
Newsgroups: comp.os.linux
Path: gmd.de!xlink.net!math.fu-berlin.de!news.netmbx.de!Germany.EU.net!
mcsun!uunet!wyvern!taylor.wyvern.com!mark
From: m...@taylor.uucp (Mark A. Davis)
Subject: Re: Linux/SCO
Organization: Lake Taylor Hospital Computer Services
Date: Fri, 06 Aug 1993 12:51:43 GMT
Message-ID: <1993Aug06.125143.14211@taylor.uucp>
References: <1993Jul26.040437.1691@taylor.uucp>
<1993Jul28.015719.13103@desaster.hanse.de> <1993Jul28.181223.11097@taylor.uucp>
<CBB3pv.KG8@ra.nrl.navy.mil>
Lines: 27
e...@tantalus.nrl.navy.mil (Eric Youngdale) writes:
>In article <1993Jul28.181223.11...@taylor.uucp> m...@taylor.uucp
(Mark A. Davis) writes:
>>>The other way round, elf-binaries for Linux, was tackled by some guys on
>>>the net, but then they seemed to fade away...?
> No, I am still here. I have been working on merging the various
>required patches with the distribution kernel a bit at a time. There was quite
>a bit, but we are getting quite close...
[...]
>>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).
--
/--------------------------------------------------------------------------\
| Mark A. Davis | Lake Taylor Hospital | Norfolk, VA (804)-461-5001x431 |
| Sys.Administrator| Computer Services | m...@taylor.wyvern.com .uucp |
\--------------------------------------------------------------------------/
Path: gmd.de!rrz.uni-koeln.de!news.dfn.de!scsing.switch.ch!news.univie.ac.at!
paladin.american.edu!gatech!prism!gt8134b
From: gt81...@prism.gatech.EDU (Howlin' Bob)
Newsgroups: comp.os.linux
Subject: Re: was Linux/SCO
Message-ID: <107886@hydra.gatech.EDU>
Date: 7 Aug 93 18:39:32 GMT
References: <1993Jul26.040437.1691@taylor.uucp>
<1993Jul28.015719.13103@desaster.hanse.de> <1993Jul28.181223.11097@taylor.uucp>
<CBB3pv.KG8@ra.nrl.navy.mil> <1993Aug06.125143.14211@taylor.uucp>
Organization: Georgia Institute of Technology
Lines: 63
In <1993Aug06.125143.14...@taylor.uucp> m...@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: gt81...@prism.gatech.edu
Newsgroups: comp.os.linux
Path: gmd.de!xlink.net!sol.ctr.columbia.edu!spool.mu.edu!darwin.sura.net!
ra!tantalus.nrl.navy.mil!eric
From: e...@tantalus.nrl.navy.mil (Eric Youngdale)
Subject: Re: was Linux/SCO
Message-ID: <CBICBL.BDt@ra.nrl.navy.mil>
Sender: use...@ra.nrl.navy.mil
Organization: Naval Research Laboratory
References: <CBB3pv.KG8@ra.nrl.navy.mil> <1993Aug06.125143.14211@taylor.uucp>
<107886@hydra.gatech.EDU>
Date: Mon, 9 Aug 1993 19:47:44 GMT
Lines: 131
In article <107...@hydra.gatech.EDU> gt81...@prism.gatech.EDU (Howlin' Bob)
writes:
>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
Oh, no. My secret plans have been revealed... :-).
>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.
This is indeed the agenda, although I have not really tried to hide it
from anyone. The a.out format that we are currently using is probably the
oldest format around, and it suffers from a lot of limitations. There is a
real elegance to the ELF approach. I should point out however that it is
possible to still have fixed address shared libraries with ELF, and thereby
avoid the -fPIC compiler option (there is a slight performance hit that you
take when using this). The advantage of ELF is that commonly used libraries
can be loaded at fixed addresses while rarely used ones could be PIC. The
loader is basically ready - all we need now is a reliable GNU ld/as/etc.
>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.
Yes, last night I got ELF going again with the latest ALPHA-diff, and
as a bonus I also re-implemented the unmapped-page0 format (you get a
segmentation fault if you attempt to dereference a null pointer). It was all
pretty easy, and the diffs are only about 20Kb. I can mail these to anyone who
wants them. I will be doing some further testing on them to make sure that
there are no hidden surprises. Adding COFF should not be that hard, although I
should point out that it may be possible to write a coff2elf converter similar
to what SVr4 uses and thus we can avoid patching the kernel to support the COFF
format.
>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 am not sure if this extra intelligence is really needed or not. As
it turns out there are two different ways that pages can be shared, and one of
them is as you mention. Even if the same file is mapped at different
addresses, the fact that the buffer cache is shared with code and data also
allow you to share pages. It is as if there are two different mechanisms
present in the kernel to allow you to share pages (perhaps one of these is now
dead code and can be removed... I need to think about it some more).
>I imagine Eric has access to a SVR4 system, so ELF compatibility is
>more important to him. Perhaps once the multiple-executable format
Indeed this is the case. I have no access to a SCO system with COFF
binaries, so development and testing is much harder. I do have a iBSC2 book,
but apparently SCO has extended the specification quite a bit (I imagine that
the same extensions are in SVr4 as well, but I cannot check this).
>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).
We are about at the point where we need volunteers to help out with
this. I have created a mail channel on the mail-net for these issues. I have
not gotten the confirmation yet, but by the time you read this it should be
ready so I invite all interested parties to join. The request address is:
linux-activists-requ...@niksula.hut.fi, the regular address is
linux-activi...@niksula.hut.fi. To send mail to the channel, you need to use
something like:
To: linux-activi...@niksula.hut.fi
Subject: Whatever.
X-Mn-Key: IBSC2
--text follows this line--
Instructions for joining are appended to the end of this message. The COFF and
ELF efforts are closely related, so for the time being the channel will cover
both.
>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
I have heard unkind things about shared libraries under SCO. The real
point to this is being able to run shrink wrapped binaries under linux, and if
the shrink wrapped binaries tend to be staticly linked, then I would suggest
that we not concern ourselves with the COFF style of shared libraries.
>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.
I have already written some code to do the easy ones that are in the
iBSC2 book, but the SCO extensions and the harder ones (i.e. ioctl) are not
done.
-Eric
II.06) How can I join the channel XXX on the linux-activists
mailing list?
ANSWER: just send a mail to the request address with help in the body;
you will get back a mail which gives you the list of channels and the
way to join/leave them. Basically you send mail to the request address
with the line:
X-Mn-Admin: join <channel>
II.07) How can I leave the channel XXX on the linux-activists
mailing list?
ANSWER: Same as above, basically. You send mail to the request address
that contains the line:
X-Mn-Admin: leave <channel>
--
"When Gregor Samsa woke up one morning from unsettling dreams, he
found himself changed in his bed into a lawyer."