[parisc-linux] HP-UX binary compatibility

[parisc-linux] HP-UX binary compatibility

[John Marvin]

I just committed a patch that restores some of the elementary HP-UX
binary compatibility functionality. Shared libraries also work. But
there is a ton of more work to do. Lots of wrappers need to be written
(see the arch/parisc/hpux directory for files that contain the support
for this functionality). One major missing piece is signal support.
Mapping ioctl arguments is another significant effort ...

John

Re: [parisc-linux] HP-UX binary compatibility

[Nathan Neulinger]

John Marvin wrote:
> 
> I just committed a patch that restores some of the elementary HP-UX
> binary compatibility functionality. Shared libraries also work. But
> there is a ton of more work to do. Lots of wrappers need to be written
> (see the arch/parisc/hpux directory for files that contain the support
> for this functionality). One major missing piece is signal support.
> Mapping ioctl arguments is another significant effort ...
> 
> John
> 
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/cgi-bin/mailman/listinfo/parisc-linux

Fantastic! I'll definately take a closer look now and will submit
whatever improvements I can!

-- Nathan

------------------------------------------------------------
Nathan Neulinger                       EMail:  nneul@umr.edu
University of Missouri - Rolla         Phone: (573) 341-4841
Computing Services                       Fax: (573) 341-4216

RE: [parisc-linux] HP-UX binary compatibility

[Neulinger, Nathan]

Cool. Looks to be working. 

Looks like the most noticeable missing syscalls are the sig* ones as you've
mentioned below. (Would be nice to get a syscall wrapper lookup table so it
at least would spit out the name of the unwrapped syscall.)

Is there any reasonable way to trace the hpux binaries? strace doesn't see
anything past the exec. Looks like I'm able to run lmutil/lmgrd, but they
get a hostid of 0. 

It's the uname call that's returning the zero:

inst2:/products/hpux# chroot /products/hpux /uname -a
Linux inst2 2.4.9-pa #3 Thu O parisc inst2 #3 Thu O
inst2:/products/hpux# chroot /products/hpux /uname -i
inst2

troot-halley(11)> uname -a
HP-UX halley B.10.20 A 9000/735 2002000004 two-user license
troot-halley(12)> uname -i
2002000004

It's that 2002000004 that I need. That appears to be the idnumber field of
the uname results. Should be simple enough to adjust the system call code as
needed, especially since I'll just need to return a known value in my case.
(Presuming that's the mechanism the the lmgrd fetches is with. If it uses
the lanscan approach, that'll be harder.)

-- Nathan

> -----Original Message-----
> From: John Marvin [mailto:jsm@udlkern.fc.hp.com]
> Sent: Thursday, October 04, 2001 6:57 AM
> To: parisc-linux@lists.parisc-linux.org
> Subject: [parisc-linux] HP-UX binary compatibility
> 
> 
> 
> I just committed a patch that restores some of the elementary HP-UX
> binary compatibility functionality. Shared libraries also work. But
> there is a ton of more work to do. Lots of wrappers need to be written
> (see the arch/parisc/hpux directory for files that contain the support
> for this functionality). One major missing piece is signal support.
> Mapping ioctl arguments is another significant effort ...
> 
> John
> 
> 
> 
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/cgi-bin/mailman/listinfo/parisc-linux
> 

Re: [parisc-linux] HP-UX binary compatibility

[Helge Deller]

Hi Nathan,

On Thursday 04 October 2001 17:07, Neulinger, Nathan wrote:
>
> troot-halley(11)> uname -a
> HP-UX halley B.10.20 A 9000/735 2002000004 two-user license
> troot-halley(12)> uname -i
> 2002000004
>
> It's that 2002000004 that I need. 

I currently don't have access to a parisc-linux machine, but out of 
my head I think you may get that number from the /proc/cpuinfo file 
(maybe it is displayed there in hex) and may use it from the variable
behind this output for your syscall wrapper.

Greetings,
Helge

RE: [parisc-linux] HP-UX binary compatibility

[Neulinger, Nathan]

I'm just getting my feet wet in this, but this didn't work:

int hpux_sysfs(int opcode, unsigned long arg1, unsigned long arg2)
{
/*Unimplemented HP-UX syscall emulation. Syscall #334 (sysfs)
  Args: 1 80057bf4 0 400179f0 0 0 0 */

        if ( opcode == 1 ) { /* GETFSIND */
                printk(KERN_DEBUG "hpux_sysfs called with '%s'", (char
*)arg1);
        }

        printk(KERN_DEBUG "hpux_sysfs called with opcode = %d\n", opcode);
}

If I comment out that if block, it runs just fine. Is there a call I should
use to make sure an address is safe prior to using it? (i.e. so I don't
cause an oops?) I get an immediate dump on the console as soon as I run the
app I'm testing.

BTW, w/ a couple of small stub wrappers, I've been able to get flexlm to run
and serve licenses, and have lmdiag say it's working (and can check out
licenses), but for some reason client applications are not working, so I'm
just trying to add any missing syscals it uses where possible to see if I
can figure out the problem. 

-- Nathan

> -----Original Message-----
> From: John Marvin [mailto:jsm@udlkern.fc.hp.com]
> Sent: Thursday, October 04, 2001 6:57 AM
> To: parisc-linux@lists.parisc-linux.org
> Subject: [parisc-linux] HP-UX binary compatibility
> 
> 
> 
> I just committed a patch that restores some of the elementary HP-UX
> binary compatibility functionality. Shared libraries also work. But
> there is a ton of more work to do. Lots of wrappers need to be written
> (see the arch/parisc/hpux directory for files that contain the support
> for this functionality). One major missing piece is signal support.
> Mapping ioctl arguments is another significant effort ...
> 
> John
> 
> 
> 
> _______________________________________________
> parisc-linux mailing list
> parisc-linux@lists.parisc-linux.org
> http://lists.parisc-linux.org/cgi-bin/mailman/listinfo/parisc-linux
> 

Re: [parisc-linux] HP-UX binary compatibility

[Matthew Wilcox]

On Thu, Oct 04, 2001 at 12:58:18PM -0500, Neulinger, Nathan wrote:
> int hpux_sysfs(int opcode, unsigned long arg1, unsigned long arg2)
> {
> /*Unimplemented HP-UX syscall emulation. Syscall #334 (sysfs)
>   Args: 1 80057bf4 0 400179f0 0 0 0 */
> 
>         if ( opcode == 1 ) { /* GETFSIND */
>                 printk(KERN_DEBUG "hpux_sysfs called with '%s'", (char
> *)arg1);
>         }
> 
>         printk(KERN_DEBUG "hpux_sysfs called with opcode = %d\n", opcode);
> }

You can't do that.  `arg1' points to a user address, not a kernel
address.  You need to use things like strlen_user and copy_from_user --
see include/asm-parisc/uaccess.h.

-- 
Revolutions do not require corporate support.

RE: [parisc-linux] HP-UX binary compatibility

[Neulinger, Nathan]

Hey, thanks. That's exactly what I needed... Got it working now. 

I've added a bunch more direct syscall calls (for the most part, call
behavior looked close enough or same in man pages) and some stub wrappers.
statfs seems semi-functional as moment, but not quite correct since a few
fields are returned as garbage (just calling real one at moment and ignoring
extra hp fields).

I'll send a patch tomorrow maybe to add some of these. i'm sure some leaves
a lot to be desired, but it's at least a bit more functional for some stuff
I've tested. 

-- Nathan

> -----Original Message-----
> From: Matthew Wilcox [mailto:willy@debian.org]
> Sent: Thursday, October 04, 2001 3:10 PM
> To: Neulinger, Nathan
> Cc: parisc-linux@lists.parisc-linux.org
> Subject: Re: [parisc-linux] HP-UX binary compatibility
> 
> 
> On Thu, Oct 04, 2001 at 12:58:18PM -0500, Neulinger, Nathan wrote:
> > int hpux_sysfs(int opcode, unsigned long arg1, unsigned long arg2)
> > {
> > /*Unimplemented HP-UX syscall emulation. Syscall #334 (sysfs)
> >   Args: 1 80057bf4 0 400179f0 0 0 0 */
> > 
> >         if ( opcode == 1 ) { /* GETFSIND */
> >                 printk(KERN_DEBUG "hpux_sysfs called with 
> '%s'", (char
> > *)arg1);
> >         }
> > 
> >         printk(KERN_DEBUG "hpux_sysfs called with opcode = 
> %d\n", opcode);
> > }
> 
> You can't do that.  `arg1' points to a user address, not a kernel
> address.  You need to use things like strlen_user and 
> copy_from_user --
> see include/asm-parisc/uaccess.h.
> 
> -- 
> Revolutions do not require corporate support.
> 

RE: [parisc-linux] HP-UX binary compatibility

[Neulinger, Nathan]

Got a question of how best to do something - flexlm does the lanscan style
open of /dev/lan, /dev/lan0...15 to try and figure out the local hardware
address of the machine:

24240: open("/dev/lan", O_RDONLY) = -1 ENOENT (No such file or directory)
24240: open("/dev/lan", O_RDONLY) = -1 ENOENT (No such file or directory)
24240: open("/dev/lan0", O_RDONLY) = 9
24240: ioctl(9 [/dev/lan0], NETSTAT, 0x7b03bc28) = 0
24240: sigprocmask(2, 0x7b038a80, 0x7b03cf28) = 0
24240: sigprocmask(2, 0x7b03cf28, 0) = 0
24240: close(9 [/dev/lan0]) = 0
24240: time(0) = 0x3bbcd084
24240: write(1 [fluent.log], 0x7b028000, 66) = 66

What do y'all think is the best way of dealing with this? I could add the
wrapper that traps the open system call, and then special case handle an
open of /dev/lan*, and somehow keep track of that file descriptor in a
global var of some sort, and then test for that fd in a wrapped ioctl
handler? 

Or would there be some nicer way of dealing with this?

Then again, I suppose I could also just return legit info on any NETSTAT
ioctl on any open fd and just have the open of /dev/lan really open
/dev/null. That might be the simplest way to get it working. 

Of course, at the moment, flexlm isn't working for the uname case either -
interestingly, lmstat and lmdiag say it's working fine, but the actual app
that tries to check out a license gets a "internal license error", so I'm
missing something somewhere still, just got to find it. Sure would be nice
if strace worked on hpux executables or the ptrace call worked. 

-- Nathan

> -----Original Message-----
> From: Neulinger, Nathan 
> Sent: Thursday, October 04, 2001 3:57 PM
> To: 'Matthew Wilcox'
> Cc: parisc-linux@lists.parisc-linux.org
> Subject: RE: [parisc-linux] HP-UX binary compatibility
> 
> 
> Hey, thanks. That's exactly what I needed... Got it working now. 
> 
> I've added a bunch more direct syscall calls (for the most 
> part, call behavior looked close enough or same in man pages) 
> and some stub wrappers. statfs seems semi-functional as 
> moment, but not quite correct since a few fields are returned 
> as garbage (just calling real one at moment and ignoring 
> extra hp fields).
> 
> I'll send a patch tomorrow maybe to add some of these. i'm 
> sure some leaves a lot to be desired, but it's at least a bit 
> more functional for some stuff I've tested. 
> 
> -- Nathan
> 
> > -----Original Message-----
> > From: Matthew Wilcox [mailto:willy@debian.org]
> > Sent: Thursday, October 04, 2001 3:10 PM
> > To: Neulinger, Nathan
> > Cc: parisc-linux@lists.parisc-linux.org
> > Subject: Re: [parisc-linux] HP-UX binary compatibility
> > 
> > 
> > On Thu, Oct 04, 2001 at 12:58:18PM -0500, Neulinger, Nathan wrote:
> > > int hpux_sysfs(int opcode, unsigned long arg1, unsigned long arg2)
> > > {
> > > /*Unimplemented HP-UX syscall emulation. Syscall #334 (sysfs)
> > >   Args: 1 80057bf4 0 400179f0 0 0 0 */
> > > 
> > >         if ( opcode == 1 ) { /* GETFSIND */
> > >                 printk(KERN_DEBUG "hpux_sysfs called with 
> > '%s'", (char
> > > *)arg1);
> > >         }
> > > 
> > >         printk(KERN_DEBUG "hpux_sysfs called with opcode = 
> > %d\n", opcode);
> > > }
> > 
> > You can't do that.  `arg1' points to a user address, not a kernel
> > address.  You need to use things like strlen_user and 
> > copy_from_user --
> > see include/asm-parisc/uaccess.h.
> > 
> > -- 
> > Revolutions do not require corporate support.
> > 
> 

Re: [parisc-linux] HP-UX binary compatibility

[Richard Hirst]

On Thu, Oct 04, 2001 at 04:16:52PM -0500, Neulinger, Nathan wrote:
> Got a question of how best to do something - flexlm does the lanscan style
> open of /dev/lan, /dev/lan0...15 to try and figure out the local hardware
> address of the machine:
> 
> 24240: open("/dev/lan", O_RDONLY) = -1 ENOENT (No such file or directory)
> 24240: open("/dev/lan", O_RDONLY) = -1 ENOENT (No such file or directory)
> 24240: open("/dev/lan0", O_RDONLY) = 9
> 24240: ioctl(9 [/dev/lan0], NETSTAT, 0x7b03bc28) = 0
> 24240: sigprocmask(2, 0x7b038a80, 0x7b03cf28) = 0
> 24240: sigprocmask(2, 0x7b03cf28, 0) = 0
> 24240: close(9 [/dev/lan0]) = 0
> 24240: time(0) = 0x3bbcd084
> 24240: write(1 [fluent.log], 0x7b028000, 66) = 66
> 
> What do y'all think is the best way of dealing with this? I could add the
> wrapper that traps the open system call, and then special case handle an
> open of /dev/lan*, and somehow keep track of that file descriptor in a
> global var of some sort, and then test for that fd in a wrapped ioctl
> handler? 
> 
> Or would there be some nicer way of dealing with this?
> 
> Then again, I suppose I could also just return legit info on any NETSTAT
> ioctl on any open fd and just have the open of /dev/lan really open
> /dev/null. That might be the simplest way to get it working. 

One alternative approach might be to load a kernel module that provides
a driver for /dev/lan.

RE: [parisc-linux] HP-UX binary compatibility

[Neulinger, Nathan]

Hmm... Doesn't appear to be in there. At the moment, I actually could care
less about the real host id, but if the proc entry was overwritable, that
would solve my needs perfectly. At the moment, in my local kernel source, I
just wired the appropriate return values in the system call wrapper. 

-- Nathan

> -----Original Message-----
> From: Helge Deller [mailto:helge.deller@sap.com]
> Sent: Friday, October 05, 2001 3:18 AM
> To: Neulinger, Nathan; 'John Marvin';
> parisc-linux@lists.parisc-linux.org
> Cc: Uetrecht, Daniel J.
> Subject: Re: [parisc-linux] HP-UX binary compatibility
> 
> 
> Hi Nathan,
> 
> On Thursday 04 October 2001 17:07, Neulinger, Nathan wrote:
> >
> > troot-halley(11)> uname -a
> > HP-UX halley B.10.20 A 9000/735 2002000004 two-user license
> > troot-halley(12)> uname -i
> > 2002000004
> >
> > It's that 2002000004 that I need. 
> 
> I currently don't have access to a parisc-linux machine, but out of 
> my head I think you may get that number from the /proc/cpuinfo file 
> (maybe it is displayed there in hex) and may use it from the variable
> behind this output for your syscall wrapper.
> 
> Greetings,
> Helge
> 

Re: [parisc-linux] HP-UX binary compatibility

[Helge Deller]

Hi Nathan,

I just verified and the /proc/cpuinfo entry was removed in the meantime.
But with the following code-fragment you will get the right number:

#include <asm/processor.h>
printk("ID: %ld\n", boot_cpu_data.pdc.model.sw_id);

This value is initialized during boot-up in setup.c and comes from the 
PDC_MODEL [pdc_model_info()] syscall.

Greetings,
Helge

On Friday 05 October 2001 17:14, Neulinger, Nathan wrote:
> Hmm... Doesn't appear to be in there. At the moment, I actually could care
> less about the real host id, but if the proc entry was overwritable, that
> would solve my needs perfectly. At the moment, in my local kernel source, I
> just wired the appropriate return values in the system call wrapper.
>
> -- Nathan
>
> > -----Original Message-----
> > From: Helge Deller [mailto:helge.deller@sap.com]
> > Sent: Friday, October 05, 2001 3:18 AM
> > To: Neulinger, Nathan; 'John Marvin';
> > parisc-linux@lists.parisc-linux.org
> > Cc: Uetrecht, Daniel J.
> > Subject: Re: [parisc-linux] HP-UX binary compatibility
> >
> >
> > Hi Nathan,
> >
> > On Thursday 04 October 2001 17:07, Neulinger, Nathan wrote:
> > > troot-halley(11)> uname -a
> > > HP-UX halley B.10.20 A 9000/735 2002000004 two-user license
> > > troot-halley(12)> uname -i
> > > 2002000004
> > >
> > > It's that 2002000004 that I need.
> >
> > I currently don't have access to a parisc-linux machine, but out of
> > my head I think you may get that number from the /proc/cpuinfo file
> > (maybe it is displayed there in hex) and may use it from the variable
> > behind this output for your syscall wrapper.
> >
> > Greetings,
> > Helge