HPUX binary compatibility
Quoted 12 lines
From: Stan Sieler <[email protected]>
Subject: Re: [parisc-linux] HPUX binary compatibility
To: [email protected] (Matthew Wilcox)
Date: Mon, 21 Jun 1999 10:23:17 -0700 (PDT)Hi,
Quoted 4 lines
Quoted 1 line
Just write translators on the hpux emulation side.
Yes, this is certainly what we'll do. But if we can be clever and get a bunch of compatibility for free, then we should.
Quoted 10 lines
The problem with translators is that they don't work in all cases.
The most important case is where you want to link some .o files
together: some are compiled for Linux, some for HP-UX.*That's* why having different system call numbers is important.
Signature · 2 lines
Stan Sieler [email protected] http://www.allegro.com/sieler/
Yow, that is an ambitious goal! I can see the desirability of doing it this way, but I am afraid it may not work. No example comes to mind but I worry about subtle assumptions in code written for HP-UX; i.e., merely defining your structures and constants the same as HP-UX may not be enough.
Like Jeff said, we got by (and still do) by either building such applications on an HP-UX box or using an emulated HP-UX environment to create real HP-UX binaries.
Hmm...just read Stan's last message. There seems to be some confusion about what we do for compatibility. When we exec a binary, it is identified as either being HP-UX or "native" (BSD). That determines which syscall mapping is used. There is no need to have distinct name spaces this way.
Does no other Linux port provide native OS compatibility?
Re:
Quoted 1 line
Yow, that is an ambitious goal! I can see the desirability of doing it
Yes...I've been trying to get MPE/iX to support HP-UX binaries via this method for a number of years, but HP hasn't shown much interest.
The reason I like it is that it removes the slightly obscene distinction of a "linux process" vs. "HP-UX process".
(MPE/iX, which also runs on PA-RISC, and which has an internal emulator for the Classic (CISC) HP 3000 instruction set, was originally going to have a similar distinction: Native Mode process vs. Compatibility Mode process ... but people pointed out, quite correctly, that a process might want
to switch from NM to CM to NM ... so a process is just a process ... the NM/CM mode is no longer a type of process.)
What does the MPE example have to do with Linux? Everything...what happens when your "linux process" wants to dynamically load code from an HP-UX library? Or vice versa? What about shared libraries?
Take it from someone who's been there: having a "process type" isn't a 100% solution. Having non-overlapping system call mechanism (either different numbers or a different address) provides a much closer to 100% solution. You may still need to translate things to provide data back to an HP-UX system call (e.g., process structure for pstat?), but that's *doable* ... and the translator method won't get that far!
Signature · 2 lines
Stan Sieler [email protected] http://www.allegro.com/sieler/