[Linux-ia64] platform detection at run-time

[Linux-ia64] platform detection at run-time

[Sane_Purushottam]

I have a linux application running on 32-bit machines. Due to some
third-party limitations, we cannot build this application on 64-bit machines
natively. Thus we'll be using the '32-bit compatibility mode'.

For some application specific reasons, I need to be able to determine at
run-time whether the application is running on a 32-bit or a 64-bit
platform.

What I have found is that there's no reliable way for the application to
determine whether it's running on a 64-bit machine. I use info obtained from
/proc/cpuinfo (more specifically family field) to determine the platform.
However this is not standard. On Redhat 7.1 (lk 2.4.3-12) family value is
set to IA-64 while on Redhat 7.2 (lk 2.4.9-34) this field is set to
'Itanium'.

What is the preferred method to determine the platform at run time ?? Are
these values likely to change (after I change my code to handle this) ????

Nitin Sane
sane_purushottam@emc.com
(508) 382-7319

Re: [Linux-ia64] platform detection at run-time

[Don Dugger]

What's wrong with `uname -m'?

On Wed, Sep 25, 2002 at 02:18:51PM -0400, Sane_Purushottam@emc.com wrote:
> I have a linux application running on 32-bit machines. Due to some
> third-party limitations, we cannot build this application on 64-bit machines
> natively. Thus we'll be using the '32-bit compatibility mode'.
> 
> For some application specific reasons, I need to be able to determine at
> run-time whether the application is running on a 32-bit or a 64-bit
> platform.
> 
> What I have found is that there's no reliable way for the application to
> determine whether it's running on a 64-bit machine. I use info obtained from
> /proc/cpuinfo (more specifically family field) to determine the platform.
> However this is not standard. On Redhat 7.1 (lk 2.4.3-12) family value is
> set to IA-64 while on Redhat 7.2 (lk 2.4.9-34) this field is set to
> 'Itanium'.
> 
> What is the preferred method to determine the platform at run time ?? Are
> these values likely to change (after I change my code to handle this) ????
> 
> Nitin Sane
> sane_purushottam@emc.com
> (508) 382-7319
> 
> 
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64

-- 
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
n0ano@n0ano.com

Re: [Linux-ia64] platform detection at run-time

[Nathan Straz]

On Wed, Sep 25, 2002 at 02:18:51PM -0400, Sane_Purushottam@emc.com wrote:
> What is the preferred method to determine the platform at run time ?? Are
> these values likely to change (after I change my code to handle this) ????

I had to do the same thing for an application and I ended up forking off
a process to run the uname command.  
-- 
Nate Straz                                              nstraz@sgi.com
sgi, inc                                           http://www.sgi.com/
Linux Test Project                                  http://ltp.sf.net/

Re: [Linux-ia64] platform detection at run-time

[David Mosberger]

>>>>> On Wed, 25 Sep 2002 14:18:51 -0400, Sane_Purushottam@emc.com said:

  Sane> What is the preferred method to determine the platform at run
  Sane> time ?? Are these values likely to change (after I change my
  Sane> code to handle this) ????

The x86 CPUID instruction will set bit 30 in EDX to indicate that it's
actually an IA-64 processor.

	--david

Re: [Linux-ia64] platform detection at run-time

[David Mosberger]

>>>>> On Wed, 25 Sep 2002 13:35:43 -0500, Nathan Straz <nstraz@sgi.com> said:

  Nathan> On Wed, Sep 25, 2002 at 02:18:51PM -0400,
  Nathan> Sane_Purushottam@emc.com wrote:
  >> What is the preferred method to determine the platform at run
  >> time ?? Are these values likely to change (after I change my code
  >> to handle this) ????

  Nathan> I had to do the same thing for an application and I ended up
  Nathan> forking off a process to run the uname command.

That doesn't work.  On a properly configured machine,
execve("/bin/uname") will return i686 when execute from an x86
process.

	--david

Re: [Linux-ia64] platform detection at run-time

[Nathan Straz]

On Wed, Sep 25, 2002 at 11:48:47AM -0700, David Mosberger wrote:
> >>>>> On Wed, 25 Sep 2002 13:35:43 -0500, Nathan Straz <nstraz@sgi.com> said:
>   Nathan> I had to do the same thing for an application and I ended up
>   Nathan> forking off a process to run the uname command.
> 
> That doesn't work.  On a properly configured machine,
> execve("/bin/uname") will return i686 when execute from an x86
> process.

What are the puzzle pieces of a "properly configured machine?"  It's
worked on all Redhat 7.2 based systems I've run.  

-- 
Nate Straz                                              nstraz@sgi.com
sgi, inc                                           http://www.sgi.com/
Linux Test Project                                  http://ltp.sf.net/

Re: [Linux-ia64] platform detection at run-time

[Joe Griffin]

I read /proc/cpuinfo and look for
anything related to IA64, anything else
I call I686:

         /*
         ** Scan for desired fields.  The "++" in front of the
         ** "k" is to skip the blank after the colon.
         **
         ** IA32:
         ** vendor_id       : GenuineIntel
         ** cpu family      : 15
         ** model           : 0
         ** model name,e.g. : Intel(R) Pentium(R) 4 CPU 1500MHz
         **
         ** IA64/Itanium:
         ** vendor     : GenuineIntel
         ** family     : IA-64
         ** model      : Itanium
         **
         ** IA64/McKinley
         ** vendor     : GenuineIntel
         ** arch       : IA-64
         ** family     : McKinley
         ** model      : 0
         **
         */
         if ( strcmp(&string[k],"Itanium ") = 0 ) {
            (void) strcpy(cpuname,&string[k]);
            sys.arch   = "linux64";
            sys.rawid  = 64;
            sys.config = 6401;
         } else if ( strcmp(&string[k],"Itanium 2 ") = 0 ) {
            (void) strcpy(cpuname,&string[k]);
            sys.arch   = "linux64";
            sys.rawid  = 64;
            sys.config = 6402;
         } else if ( strcmp(&string[k],"McKinley ") = 0 ) {
            (void) strcpy(cpuname,&string[k]);
            sys.arch   = "linux64";
            sys.rawid  = 64;
            sys.config = 6402;
         } else if ( strcmp(&string[i],"model name") = 0 ) {
            (void) strcpy(cpuname,&string[k]);
            sys.arch   = "linux";
            sys.rawid  = 686;
            sys.config = 686;

Joe
   
David Mosberger wrote:

>>>>>>On Wed, 25 Sep 2002 13:35:43 -0500, Nathan Straz <nstraz@sgi.com> said:
>>>>>>            
>>>>>>
>
>  Nathan> On Wed, Sep 25, 2002 at 02:18:51PM -0400,
>  Nathan> Sane_Purushottam@emc.com wrote:
>  >> What is the preferred method to determine the platform at run
>  >> time ?? Are these values likely to change (after I change my code
>  >> to handle this) ????
>
>  Nathan> I had to do the same thing for an application and I ended up
>  Nathan> forking off a process to run the uname command.
>
>That doesn't work.  On a properly configured machine,
>execve("/bin/uname") will return i686 when execute from an x86
>process.
>
>	--david
>
>_______________________________________________
>Linux-IA64 mailing list
>Linux-IA64@linuxia64.org
>http://lists.linuxia64.org/lists/listinfo/linux-ia64
>
>
>  
>

Re: [Linux-ia64] platform detection at run-time

[David Mosberger]

>>>>> On Wed, 25 Sep 2002 13:57:38 -0500, Nathan Straz <nstraz@sgi.com> said:

  Nathan> What are the puzzle pieces of a "properly configured
  Nathan> machine?"  It's worked on all Redhat 7.2 based systems I've
  Nathan> run.

It's wrong if execve("/bin/uname") returns a different value than the
x86 uname() system call.  To ensure consistency, it is necessary to
install the x86 version of uname in /emul/ia32-linux/bin/.

I'd hope that stuff like this will eventually be spelled out in the
LSB documents.

	--david

RE: [Linux-ia64] platform detection at run-time

[Van Maren, Kevin]

Nitin,

Have you decided what you want to do about AMD's x86-64?
That is another 64-bit platform that will run your 32-bit binary.

Ideally all three platforms would be enough alike you don't
have to worry about it: is there a problem with Linux that is
causing you to perform this check?

Kevin

-----Original Message-----
From: Sane_Purushottam@emc.com
To: linux-ia64@linuxia64.org
Cc: Sane_Purushottam@emc.com
Sent: 9/25/02 2:18 PM
Subject: [Linux-ia64] platform detection at run-time

I have a linux application running on 32-bit machines. Due to some
third-party limitations, we cannot build this application on 64-bit
machines
natively. Thus we'll be using the '32-bit compatibility mode'.

For some application specific reasons, I need to be able to determine at
run-time whether the application is running on a 32-bit or a 64-bit
platform.

What I have found is that there's no reliable way for the application to
determine whether it's running on a 64-bit machine. I use info obtained
from
/proc/cpuinfo (more specifically family field) to determine the
platform.
However this is not standard. On Redhat 7.1 (lk 2.4.3-12) family value
is
set to IA-64 while on Redhat 7.2 (lk 2.4.9-34) this field is set to
'Itanium'.

What is the preferred method to determine the platform at run time ??
Are
these values likely to change (after I change my code to handle this)
????

Nitin Sane
sane_purushottam@emc.com
(508) 382-7319


_______________________________________________
Linux-IA64 mailing list
Linux-IA64@linuxia64.org
http://lists.linuxia64.org/lists/listinfo/linux-ia64

RE: [Linux-ia64] platform detection at run-time

[Sane_Purushottam]

The reason, I have to detect the architecture at run time has to do with the
interface with (sg) driver. Since the driver is natively compiled for
64-bit, it expects the data structure handed over to it, to be 64-bit wide.
Thus my 32-bit application cannot issue ioctl calls successfully.

So, in my application, based on the platform, I fill the appropriate
structure before ioctl call.

Nitin Sane
sane_purushottam@emc.com
(508) 382-7319


-----Original Message-----
From: Van Maren, Kevin [mailto:kevin.vanmaren@unisys.com]
Sent: Wednesday, September 25, 2002 3:28 PM
To: 'Sane_Purushottam@emc.com '; 'linux-ia64@linuxia64.org '
Subject: RE: [Linux-ia64] platform detection at run-time


Nitin,

Have you decided what you want to do about AMD's x86-64?
That is another 64-bit platform that will run your 32-bit binary.

Ideally all three platforms would be enough alike you don't
have to worry about it: is there a problem with Linux that is
causing you to perform this check?

Kevin

-----Original Message-----
From: Sane_Purushottam@emc.com
To: linux-ia64@linuxia64.org
Cc: Sane_Purushottam@emc.com
Sent: 9/25/02 2:18 PM
Subject: [Linux-ia64] platform detection at run-time

I have a linux application running on 32-bit machines. Due to some
third-party limitations, we cannot build this application on 64-bit
machines
natively. Thus we'll be using the '32-bit compatibility mode'.

For some application specific reasons, I need to be able to determine at
run-time whether the application is running on a 32-bit or a 64-bit
platform.

What I have found is that there's no reliable way for the application to
determine whether it's running on a 64-bit machine. I use info obtained
from
/proc/cpuinfo (more specifically family field) to determine the
platform.
However this is not standard. On Redhat 7.1 (lk 2.4.3-12) family value
is
set to IA-64 while on Redhat 7.2 (lk 2.4.9-34) this field is set to
'Itanium'.

What is the preferred method to determine the platform at run time ??
Are
these values likely to change (after I change my code to handle this)
????

Nitin Sane
sane_purushottam@emc.com
(508) 382-7319


_______________________________________________
Linux-IA64 mailing list
Linux-IA64@linuxia64.org
http://lists.linuxia64.org/lists/listinfo/linux-ia64

RE: [Linux-ia64] platform detection at run-time

[Wichmann, Mats D]

>   Nathan> What are the puzzle pieces of a "properly configured
>   Nathan> machine?"  It's worked on all Redhat 7.2 based systems I've
>   Nathan> run.
> 
> It's wrong if execve("/bin/uname") returns a different value than the
> x86 uname() system call.  To ensure consistency, it is necessary to
> install the x86 version of uname in /emul/ia32-linux/bin/.
> 
> I'd hope that stuff like this will eventually be spelled out in the
> LSB documents.


Ahem.  I'm listening.  There's a draft ia64 LSB spec
available for review here:

http://www.linuxbase.org/spec/lsbia64review.html

you can also go directly to the doc from here:

http://www.linuxbase.org/spec/index.shtml

(and file bugs in the normal way through sourceforge,
which is better, since if you're logged in when you
file it you get notifications back as it progresses).

It got tagged with a close date of this Friday,
but if there's any enthusiasm forthcoming, I don't
mind keeping that open a bit longer.  Seems like
the announcement of the review period that was
supposed to go "everywhere" never did get sent to
this list, at least I don't recall seeing it.
(Prob'ly should have done that myself; sorry).

We've really kind of sidestepped some of these issues, 
for a variety of reasons.

First off, there was some effort a while back to talk
about /proc/cpuinfo, and then that was killed.  I don't
recall the whole discussion, but /proc/cpuinfo will NOT
be standardized in the LSB in the forseeable future.

Secondly, the current consensus seems to be that issues
of compatibility library and file location will be resolved
behind the scenes, so the spec should not say much about 
them. For example, an ia32 binary will be linked against
ld-linux.so.2 (or for an LSB application, ld-lsb.so.1),
and it's that dynamic linker's work to figure out
things about the libraries.  There's already, for
example, one ia32 implementation where the LSB dynamic
linker actually picks libraries out of /lib/lsb
instead of /lib or /usr/lib.  That's allowed....

The /emul/linux-i386 stuff is a path prefix supplied
by the kernel, right?  I really don't know whether
that should be mentioned in the spec or not: does
an application actually need to know that this is
happening, or is it completely transparent?  Of
course a given system has to "get it right".

I do think the issue that started this thread is worthy
of some sort of mention in the LSB.

The LSB in general is following FHS ideas, I know
that discussion spilled onto this list about a year
ago.

One thing that's been batted around is the name of
the dynamic linker:  it's been tentatively called
ld-lsb-ia64.so.1 to parallel the "standard" Linux
one, but other folks with 64-bit architectures
prefer a more generic ld-lsb-64.so.1, which would be
the same name regardless of architecture.  Since this 
doesn't affect ld-linux, there's no backwards-compatibility
issue with that name...

Anyway, any and all comments on this stuff gratefully
accepted.

Thanks,

Mats Wichmann
(if you couldn't guess, I'm Intel's current representative 
to the LSB)

RE: [Linux-ia64] platform detection at run-time

[David Mosberger]

>>>>> On Wed, 25 Sep 2002 15:33:12 -0400, Sane_Purushottam@emc.com said:

  Sane> The reason, I have to detect the architecture at run time has
  Sane> to do with the interface with (sg) driver. Since the driver is
  Sane> natively compiled for 64-bit, it expects the data structure
  Sane> handed over to it, to be 64-bit wide.  Thus my 32-bit
  Sane> application cannot issue ioctl calls successfully.

That sounds like a bug in the ia32 subsystem.

There should be no need to do anything special in user level.

	--david

Re: [Linux-ia64] platform detection at run-time

[Grant Grundler]

Sane_Purushottam@emc.com wrote:
> The reason, I have to detect the architecture at run time has to do with the
> interface with (sg) driver. Since the driver is natively compiled for
> 64-bit, it expects the data structure handed over to it, to be 64-bit wide.
> Thus my 32-bit application cannot issue ioctl calls successfully.

isn't "arch/*/kernel/ioctl32.c" the place to handle this kind of conversion?

grundler <514>fgrep SG arch/parisc/kernel/ioctl32.c
COMPATIBLE_IOCTL(FDMSGON)
COMPATIBLE_IOCTL(FDMSGOFF)
COMPATIBLE_IOCTL(FDSETEMSGTRESH)
/* SG stuff */
COMPATIBLE_IOCTL(SG_SET_TIMEOUT)
COMPATIBLE_IOCTL(SG_GET_TIMEOUT)
COMPATIBLE_IOCTL(SG_EMULATED_HOST)
COMPATIBLE_IOCTL(SG_SET_TRANSFORM)
...


ia64 seems to drop this kind of thing in arch/ia64/ia32/ia32_ioctl.c

> So, in my application, based on the platform, I fill the appropriate
> structure before ioctl call.

putting it in the application sounds like the wrong thing to do.

grant

Re: [Linux-ia64] platform detection at run-time

[Don Dugger]

Nitin-

Can you tell me exactly which ioctl calls you're using that aren't
working?  We have code in the kernel to deal with just this situation.
I didn't transform EVERY ioctl in existence so let me know which ones
you're using and I'll fix them.

On Wed, Sep 25, 2002 at 03:33:12PM -0400, Sane_Purushottam@emc.com wrote:
> The reason, I have to detect the architecture at run time has to do with the
> interface with (sg) driver. Since the driver is natively compiled for
> 64-bit, it expects the data structure handed over to it, to be 64-bit wide.
> Thus my 32-bit application cannot issue ioctl calls successfully.
> 
> So, in my application, based on the platform, I fill the appropriate
> structure before ioctl call.
> 
> Nitin Sane
> sane_purushottam@emc.com
> (508) 382-7319
> 
> 
> -----Original Message-----
> From: Van Maren, Kevin [mailto:kevin.vanmaren@unisys.com]
> Sent: Wednesday, September 25, 2002 3:28 PM
> To: 'Sane_Purushottam@emc.com '; 'linux-ia64@linuxia64.org '
> Subject: RE: [Linux-ia64] platform detection at run-time
> 
> 
> Nitin,
> 
> Have you decided what you want to do about AMD's x86-64?
> That is another 64-bit platform that will run your 32-bit binary.
> 
> Ideally all three platforms would be enough alike you don't
> have to worry about it: is there a problem with Linux that is
> causing you to perform this check?
> 
> Kevin
> 
> -----Original Message-----
> From: Sane_Purushottam@emc.com
> To: linux-ia64@linuxia64.org
> Cc: Sane_Purushottam@emc.com
> Sent: 9/25/02 2:18 PM
> Subject: [Linux-ia64] platform detection at run-time
> 
> I have a linux application running on 32-bit machines. Due to some
> third-party limitations, we cannot build this application on 64-bit
> machines
> natively. Thus we'll be using the '32-bit compatibility mode'.
> 
> For some application specific reasons, I need to be able to determine at
> run-time whether the application is running on a 32-bit or a 64-bit
> platform.
> 
> What I have found is that there's no reliable way for the application to
> determine whether it's running on a 64-bit machine. I use info obtained
> from
> /proc/cpuinfo (more specifically family field) to determine the
> platform.
> However this is not standard. On Redhat 7.1 (lk 2.4.3-12) family value
> is
> set to IA-64 while on Redhat 7.2 (lk 2.4.9-34) this field is set to
> 'Itanium'.
> 
> What is the preferred method to determine the platform at run time ??
> Are
> these values likely to change (after I change my code to handle this)
> ????
> 
> Nitin Sane
> sane_purushottam@emc.com
> (508) 382-7319
> 
> 
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64
> 
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64

-- 
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
n0ano@n0ano.com

RE: [Linux-ia64] platform detection at run-time

[Sane_Purushottam]

SG_IO. The application is sending SCSI commands to the devices.

Nitin Sane
sane_purushottam@emc.com
(508) 382-7319


-----Original Message-----
From: Don Dugger [mailto:n0ano@n0ano.com]
Sent: Wednesday, September 25, 2002 5:08 PM
To: Sane_Purushottam@emc.com
Cc: kevin.vanmaren@unisys.com; linux-ia64@linuxia64.org
Subject: Re: [Linux-ia64] platform detection at run-time


Nitin-

Can you tell me exactly which ioctl calls you're using that aren't
working?  We have code in the kernel to deal with just this situation.
I didn't transform EVERY ioctl in existence so let me know which ones
you're using and I'll fix them.

On Wed, Sep 25, 2002 at 03:33:12PM -0400, Sane_Purushottam@emc.com wrote:
> The reason, I have to detect the architecture at run time has to do with
the
> interface with (sg) driver. Since the driver is natively compiled for
> 64-bit, it expects the data structure handed over to it, to be 64-bit
wide.
> Thus my 32-bit application cannot issue ioctl calls successfully.
> 
> So, in my application, based on the platform, I fill the appropriate
> structure before ioctl call.
> 
> Nitin Sane
> sane_purushottam@emc.com
> (508) 382-7319
> 
> 
> -----Original Message-----
> From: Van Maren, Kevin [mailto:kevin.vanmaren@unisys.com]
> Sent: Wednesday, September 25, 2002 3:28 PM
> To: 'Sane_Purushottam@emc.com '; 'linux-ia64@linuxia64.org '
> Subject: RE: [Linux-ia64] platform detection at run-time
> 
> 
> Nitin,
> 
> Have you decided what you want to do about AMD's x86-64?
> That is another 64-bit platform that will run your 32-bit binary.
> 
> Ideally all three platforms would be enough alike you don't
> have to worry about it: is there a problem with Linux that is
> causing you to perform this check?
> 
> Kevin
> 
> -----Original Message-----
> From: Sane_Purushottam@emc.com
> To: linux-ia64@linuxia64.org
> Cc: Sane_Purushottam@emc.com
> Sent: 9/25/02 2:18 PM
> Subject: [Linux-ia64] platform detection at run-time
> 
> I have a linux application running on 32-bit machines. Due to some
> third-party limitations, we cannot build this application on 64-bit
> machines
> natively. Thus we'll be using the '32-bit compatibility mode'.
> 
> For some application specific reasons, I need to be able to determine at
> run-time whether the application is running on a 32-bit or a 64-bit
> platform.
> 
> What I have found is that there's no reliable way for the application to
> determine whether it's running on a 64-bit machine. I use info obtained
> from
> /proc/cpuinfo (more specifically family field) to determine the
> platform.
> However this is not standard. On Redhat 7.1 (lk 2.4.3-12) family value
> is
> set to IA-64 while on Redhat 7.2 (lk 2.4.9-34) this field is set to
> 'Itanium'.
> 
> What is the preferred method to determine the platform at run time ??
> Are
> these values likely to change (after I change my code to handle this)
> ????
> 
> Nitin Sane
> sane_purushottam@emc.com
> (508) 382-7319
> 
> 
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64
> 
> _______________________________________________
> Linux-IA64 mailing list
> Linux-IA64@linuxia64.org
> http://lists.linuxia64.org/lists/listinfo/linux-ia64

-- 
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
n0ano@n0ano.com

RE: [Linux-ia64] platform detection at run-time

[David Mosberger]

>>>>> On Wed, 25 Sep 2002 12:40:20 -0700, "Wichmann, Mats D" <mats.d.wichmann@intel.com> said:

  Mats> Ahem.  I'm listening.  There's a draft ia64 LSB spec available
  Mats> for review here:

  Mats> http://www.linuxbase.org/spec/lsbia64review.html

  Mats> you can also go directly to the doc from here:

  Mats> http://www.linuxbase.org/spec/index.shtml

  Mats> (and file bugs in the normal way through sourceforge, which is
  Mats> better, since if you're logged in when you file it you get
  Mats> notifications back as it progresses).

In the ELF header flags, I didn't see any mention of this bit:

/* Least-significant four bits of ELF header's e_flags are
   OS-specific.  The bits are interpreted as follows by Linux: */
#define EF_IA_64_LINUX_EXECUTABLE_STACK 0x1 /* is stack (& heap) executable by default? */

Might be worthwhile to document it, since it is ia64 linux specific
and hence not mentioned in the ABI.

  Mats> The /emul/linux-i386 stuff is a path prefix supplied by the
  Mats> kernel, right?  I really don't know whether that should be
  Mats> mentioned in the spec or not: does an application actually
  Mats> need to know that this is happening, or is it completely
  Mats> transparent?  Of course a given system has to "get it right".

Right, /emul/ia32-linux/ is a kernel thing.  I agree it doesn't make
much sense to describe the mechanism.  However, perhaps you might want
to document what "uname -m" ought to return when exec'd from an x86
binary.  (Where does this document talk about x86 support anyhow?)

  Mats> One thing that's been batted around is the name of the dynamic
  Mats> linker: it's been tentatively called ld-lsb-ia64.so.1 to
  Mats> parallel the "standard" Linux one, but other folks with 64-bit
  Mats> architectures prefer a more generic ld-lsb-64.so.1, which
  Mats> would be the same name regardless of architecture.  Since this
  Mats> doesn't affect ld-linux, there's no backwards-compatibility
  Mats> issue with that name...

That's a stupid idea.  The dynamic loader is the _one_ thing that's
very difficult to emulate when hosting an OS environment on a guest
OS.  The only clean way to avoid that is to give each loader a unique
name.  ld-lsb-$(uname -m).so.1 probably would be more reasonable
(assuming LSB has a VERY good reason why ld-linux-$(uname -m).so.1
isn't good enough).

Think of what would happen if you wanted to, say, emulate SPARC64
Linux binaries on an Itanium platform.  If both SPARC64 and ia64 linux
used /lib/ld-lsb-64.so.1, you'd find yourself in big trouble (and no,
the /emul/xxx-prefix doesn't help here either; it's a bootstrapping
problem...).

	--david

Re: [Linux-ia64] platform detection at run-time

[Don Dugger]

[-- Attachment #1: Type: text/plain, Size: 4122 bytes --]

Nitin-

Attached is a kernel patch that should fix the SG_IO ioctl call for
IA32 programs.  If you could test it out and let me know how it works
that would be a big help.  I don't have a test program so I haven't
tested it myself but I think it should be correct, I just lifted
code from the sparc64 port that does the same thing.

The patch is against an ia64-020821.diff patched 2.4.19 kernel.

On Wed, Sep 25, 2002 at 05:25:35PM -0400, Sane_Purushottam@emc.com wrote:
> SG_IO. The application is sending SCSI commands to the devices.
> 
> Nitin Sane
> sane_purushottam@emc.com
> (508) 382-7319
> 
> 
> -----Original Message-----
> From: Don Dugger [mailto:n0ano@n0ano.com]
> Sent: Wednesday, September 25, 2002 5:08 PM
> To: Sane_Purushottam@emc.com
> Cc: kevin.vanmaren@unisys.com; linux-ia64@linuxia64.org
> Subject: Re: [Linux-ia64] platform detection at run-time
> 
> 
> Nitin-
> 
> Can you tell me exactly which ioctl calls you're using that aren't
> working?  We have code in the kernel to deal with just this situation.
> I didn't transform EVERY ioctl in existence so let me know which ones
> you're using and I'll fix them.
> 
> On Wed, Sep 25, 2002 at 03:33:12PM -0400, Sane_Purushottam@emc.com wrote:
> > The reason, I have to detect the architecture at run time has to do with
> the
> > interface with (sg) driver. Since the driver is natively compiled for
> > 64-bit, it expects the data structure handed over to it, to be 64-bit
> wide.
> > Thus my 32-bit application cannot issue ioctl calls successfully.
> > 
> > So, in my application, based on the platform, I fill the appropriate
> > structure before ioctl call.
> > 
> > Nitin Sane
> > sane_purushottam@emc.com
> > (508) 382-7319
> > 
> > 
> > -----Original Message-----
> > From: Van Maren, Kevin [mailto:kevin.vanmaren@unisys.com]
> > Sent: Wednesday, September 25, 2002 3:28 PM
> > To: 'Sane_Purushottam@emc.com '; 'linux-ia64@linuxia64.org '
> > Subject: RE: [Linux-ia64] platform detection at run-time
> > 
> > 
> > Nitin,
> > 
> > Have you decided what you want to do about AMD's x86-64?
> > That is another 64-bit platform that will run your 32-bit binary.
> > 
> > Ideally all three platforms would be enough alike you don't
> > have to worry about it: is there a problem with Linux that is
> > causing you to perform this check?
> > 
> > Kevin
> > 
> > -----Original Message-----
> > From: Sane_Purushottam@emc.com
> > To: linux-ia64@linuxia64.org
> > Cc: Sane_Purushottam@emc.com
> > Sent: 9/25/02 2:18 PM
> > Subject: [Linux-ia64] platform detection at run-time
> > 
> > I have a linux application running on 32-bit machines. Due to some
> > third-party limitations, we cannot build this application on 64-bit
> > machines
> > natively. Thus we'll be using the '32-bit compatibility mode'.
> > 
> > For some application specific reasons, I need to be able to determine at
> > run-time whether the application is running on a 32-bit or a 64-bit
> > platform.
> > 
> > What I have found is that there's no reliable way for the application to
> > determine whether it's running on a 64-bit machine. I use info obtained
> > from
> > /proc/cpuinfo (more specifically family field) to determine the
> > platform.
> > However this is not standard. On Redhat 7.1 (lk 2.4.3-12) family value
> > is
> > set to IA-64 while on Redhat 7.2 (lk 2.4.9-34) this field is set to
> > 'Itanium'.
> > 
> > What is the preferred method to determine the platform at run time ??
> > Are
> > these values likely to change (after I change my code to handle this)
> > ????
> > 
> > Nitin Sane
> > sane_purushottam@emc.com
> > (508) 382-7319
> > 
> > 
> > _______________________________________________
> > Linux-IA64 mailing list
> > Linux-IA64@linuxia64.org
> > http://lists.linuxia64.org/lists/listinfo/linux-ia64
> > 
> > _______________________________________________
> > Linux-IA64 mailing list
> > Linux-IA64@linuxia64.org
> > http://lists.linuxia64.org/lists/listinfo/linux-ia64
> 
> -- 
> Don Dugger
> "Censeo Toto nos in Kansa esse decisse." - D. Gale
> n0ano@n0ano.com

-- 
Don Dugger
"Censeo Toto nos in Kansa esse decisse." - D. Gale
n0ano@n0ano.com

[-- Attachment #2: patch_0925.l --]
[-- Type: text/plain, Size: 7486 bytes --]

diff -Naur linux-2.4.19/arch/ia64/ia32/ia32_ioctl.c linux-2.4.19-ddd/arch/ia64/ia32/ia32_ioctl.c
--- linux-2.4.19/arch/ia64/ia32/ia32_ioctl.c	Fri Aug  2 18:39:42 2002
+++ linux-2.4.19-ddd/arch/ia64/ia32/ia32_ioctl.c	Wed Sep 25 21:27:11 2002
@@ -24,6 +24,12 @@
 #include <linux/if_ppp.h>
 #include <linux/ixjuser.h>
 #include <linux/i2o-dev.h>
+#include <scsi/scsi.h>
+/* Ugly hack. */
+#undef	__KERNEL__
+#include <scsi/scsi_ioctl.h>
+#define	__KERNEL__
+#include <scsi/sg.h>
 
 #include <asm/ia32.h>
 
@@ -56,6 +62,235 @@
 		|| put_user(d->d_reclen, &d32->d_reclen)
 		|| copy_to_user(d32->d_name, d->d_name, namelen + 1));
 }
+/*
+ *  The transform code for the SG_IO ioctl was brazenly lifted from
+ *  the Sparc64 port in the file `arch/sparc64/kernel/ioctl32.c'.
+ *  Thanks to Jakub Jelinek & Eddie C. Dost.
+ */
+typedef struct sg_io_hdr32 {
+	int interface_id;	/* [i] 'S' for SCSI generic (required) */
+	int dxfer_direction;	/* [i] data transfer direction  */
+	char  cmd_len;		/* [i] SCSI command length ( <= 16 bytes) */
+	char  mx_sb_len;		/* [i] max length to write to sbp */
+	short iovec_count;	/* [i] 0 implies no scatter gather */
+	int dxfer_len;		/* [i] byte count of data transfer */
+	int dxferp;		/* [i], [*io] points to data transfer memory
+					      or scatter gather list */
+	int cmdp;		/* [i], [*i] points to command to perform */
+	int sbp;		/* [i], [*o] points to sense_buffer memory */
+	int timeout;		/* [i] MAX_UINT->no timeout (unit: millisec) */
+	int flags;		/* [i] 0 -> default, see SG_FLAG... */
+	int pack_id;		/* [i->o] unused internally (normally) */
+	int usr_ptr;		/* [i->o] unused internally */
+	char  status;		/* [o] scsi status */
+	char  masked_status;	/* [o] shifted, masked scsi status */
+	char  msg_status;	/* [o] messaging level data (optional) */
+	char  sb_len_wr;	/* [o] byte count actually written to sbp */
+	short host_status;	/* [o] errors from host adapter */
+	short driver_status;	/* [o] errors from software driver */
+	int resid;		/* [o] dxfer_len - actual_transferred */
+	int duration;		/* [o] time taken by cmd (unit: millisec) */
+	int info;		/* [o] auxiliary information */
+} sg_io_hdr32_t;  /* 64 bytes long (on IA32) */
+
+struct iovec32 { unsigned int iov_base; int iov_len; };
+
+static int alloc_sg_iovec(sg_io_hdr_t *sgp, int uptr32)
+{
+	struct iovec32 *uiov = (struct iovec32 *) P(uptr32);
+	sg_iovec_t *kiov;
+	int i;
+
+	sgp->dxferp = kmalloc(sgp->iovec_count *
+			      sizeof(sg_iovec_t), GFP_KERNEL);
+	if (!sgp->dxferp)
+		return -ENOMEM;
+	memset(sgp->dxferp, 0,
+	       sgp->iovec_count * sizeof(sg_iovec_t));
+
+	kiov = (sg_iovec_t *) sgp->dxferp;
+	for (i = 0; i < sgp->iovec_count; i++) {
+		int iov_base32;
+		if (__get_user(iov_base32, &uiov->iov_base) ||
+		    __get_user(kiov->iov_len, &uiov->iov_len))
+			return -EFAULT;
+
+		kiov->iov_base = kmalloc(kiov->iov_len, GFP_KERNEL);
+		if (!kiov->iov_base)
+			return -ENOMEM;
+		if (copy_from_user(kiov->iov_base,
+				   (void *) P(iov_base32),
+				   kiov->iov_len))
+			return -EFAULT;
+
+		uiov++;
+		kiov++;
+	}
+
+	return 0;
+}
+
+static int copy_back_sg_iovec(sg_io_hdr_t *sgp, int uptr32)
+{
+	struct iovec32 *uiov = (struct iovec32 *) P(uptr32);
+	sg_iovec_t *kiov = (sg_iovec_t *) sgp->dxferp;
+	int i;
+
+	for (i = 0; i < sgp->iovec_count; i++) {
+		int iov_base32;
+
+		if (__get_user(iov_base32, &uiov->iov_base))
+			return -EFAULT;
+
+		if (copy_to_user((void *) P(iov_base32),
+				 kiov->iov_base,
+				 kiov->iov_len))
+			return -EFAULT;
+
+		uiov++;
+		kiov++;
+	}
+
+	return 0;
+}
+
+static void free_sg_iovec(sg_io_hdr_t *sgp)
+{
+	sg_iovec_t *kiov = (sg_iovec_t *) sgp->dxferp;
+	int i;
+
+	for (i = 0; i < sgp->iovec_count; i++) {
+		if (kiov->iov_base) {
+			kfree(kiov->iov_base);
+			kiov->iov_base = NULL;
+		}
+		kiov++;
+	}
+	kfree(sgp->dxferp);
+	sgp->dxferp = NULL;
+}
+
+static int sg_ioctl_trans(unsigned int fd, unsigned int cmd, unsigned long arg)
+{
+	sg_io_hdr32_t *sg_io32;
+	sg_io_hdr_t sg_io64;
+	int dxferp32, cmdp32, sbp32;
+	mm_segment_t old_fs;
+	int err = 0;
+
+	sg_io32 = (sg_io_hdr32_t *)arg;
+	err = __get_user(sg_io64.interface_id, &sg_io32->interface_id);
+	err |= __get_user(sg_io64.dxfer_direction, &sg_io32->dxfer_direction);
+	err |= __get_user(sg_io64.cmd_len, &sg_io32->cmd_len);
+	err |= __get_user(sg_io64.mx_sb_len, &sg_io32->mx_sb_len);
+	err |= __get_user(sg_io64.iovec_count, &sg_io32->iovec_count);
+	err |= __get_user(sg_io64.dxfer_len, &sg_io32->dxfer_len);
+	err |= __get_user(sg_io64.timeout, &sg_io32->timeout);
+	err |= __get_user(sg_io64.flags, &sg_io32->flags);
+	err |= __get_user(sg_io64.pack_id, &sg_io32->pack_id);
+
+	sg_io64.dxferp = NULL;
+	sg_io64.cmdp = NULL;
+	sg_io64.sbp = NULL;
+
+	err |= __get_user(cmdp32, &sg_io32->cmdp);
+	sg_io64.cmdp = kmalloc(sg_io64.cmd_len, GFP_KERNEL);
+	if (!sg_io64.cmdp) {
+		err = -ENOMEM;
+		goto out;
+	}
+	if (copy_from_user(sg_io64.cmdp,
+			   (void *) P(cmdp32),
+			   sg_io64.cmd_len)) {
+		err = -EFAULT;
+		goto out;
+	}
+
+	err |= __get_user(sbp32, &sg_io32->sbp);
+	sg_io64.sbp = kmalloc(sg_io64.mx_sb_len, GFP_KERNEL);
+	if (!sg_io64.sbp) {
+		err = -ENOMEM;
+		goto out;
+	}
+	if (copy_from_user(sg_io64.sbp,
+			   (void *) P(sbp32),
+			   sg_io64.mx_sb_len)) {
+		err = -EFAULT;
+		goto out;
+	}
+
+	err |= __get_user(dxferp32, &sg_io32->dxferp);
+	if (sg_io64.iovec_count) {
+		int ret;
+
+		if ((ret = alloc_sg_iovec(&sg_io64, dxferp32))) {
+			err = ret;
+			goto out;
+		}
+	} else {
+		sg_io64.dxferp = kmalloc(sg_io64.dxfer_len, GFP_KERNEL);
+		if (!sg_io64.dxferp) {
+			err = -ENOMEM;
+			goto out;
+		}
+		if (copy_from_user(sg_io64.dxferp,
+				   (void *) P(dxferp32),
+				   sg_io64.dxfer_len)) {
+			err = -EFAULT;
+			goto out;
+		}
+	}
+
+	/* Unused internally, do not even bother to copy it over. */
+	sg_io64.usr_ptr = NULL;
+
+	if (err)
+		return -EFAULT;
+
+	old_fs = get_fs();
+	set_fs (KERNEL_DS);
+	err = sys_ioctl (fd, cmd, (unsigned long) &sg_io64);
+	set_fs (old_fs);
+
+	if (err < 0)
+		goto out;
+
+	err = __put_user(sg_io64.pack_id, &sg_io32->pack_id);
+	err |= __put_user(sg_io64.status, &sg_io32->status);
+	err |= __put_user(sg_io64.masked_status, &sg_io32->masked_status);
+	err |= __put_user(sg_io64.msg_status, &sg_io32->msg_status);
+	err |= __put_user(sg_io64.sb_len_wr, &sg_io32->sb_len_wr);
+	err |= __put_user(sg_io64.host_status, &sg_io32->host_status);
+	err |= __put_user(sg_io64.driver_status, &sg_io32->driver_status);
+	err |= __put_user(sg_io64.resid, &sg_io32->resid);
+	err |= __put_user(sg_io64.duration, &sg_io32->duration);
+	err |= __put_user(sg_io64.info, &sg_io32->info);
+	err |= copy_to_user((void *)P(sbp32), sg_io64.sbp, sg_io64.mx_sb_len);
+	if (sg_io64.dxferp) {
+		if (sg_io64.iovec_count)
+			err |= copy_back_sg_iovec(&sg_io64, dxferp32);
+		else
+			err |= copy_to_user((void *)P(dxferp32),
+					    sg_io64.dxferp,
+					    sg_io64.dxfer_len);
+	}
+	if (err)
+		err = -EFAULT;
+
+out:
+	if (sg_io64.cmdp)
+		kfree(sg_io64.cmdp);
+	if (sg_io64.sbp)
+		kfree(sg_io64.sbp);
+	if (sg_io64.dxferp) {
+		if (sg_io64.iovec_count) {
+			free_sg_iovec(&sg_io64);
+		} else {
+			kfree(sg_io64.dxferp);
+		}
+	}
+	return err;
+}
 
 asmlinkage long
 sys32_ioctl (unsigned int fd, unsigned int cmd, unsigned int arg)
@@ -266,6 +501,9 @@
 		break;
 	      default:
 		return sys_ioctl(fd, cmd, (unsigned long)arg);
+
+		case IOCTL_NR(SG_IO):
+			return(sg_ioctl_trans(fd, cmd, arg));
 
 	}
 	printk("%x:unimplemented IA32 ioctl system call\n", cmd);