PATCH: 3.1.6-dev-20: runtime determination of MACHTYPE

PATCH: 3.1.6-dev-20: runtime determination of MACHTYPE

[Clint Adams]

This patch allows zsh to determine MACHTYPE at run-time, rather
than from the configure results of the build-machine, assuming
uname(2) is available.

I assume that the overhead is low enough that no one will feel
the need to disable this.

Index: configure.in
===================================================================
RCS file: /cvs/zsh/zsh/configure.in,v
retrieving revision 1.1.1.64
diff -u -r1.1.1.64 configure.in
--- configure.in	2000/03/13 01:52:19	1.1.1.64
+++ configure.in	2000/03/25 15:34:25
@@ -826,7 +826,8 @@
 	       mmap munmap msync \
 	       cap_get_proc \
 	       getrlimit \
-	       setlocale)
+	       setlocale \
+	       uname)
 AC_FUNC_STRCOLL
 
 if test $ac_cv_func_setpgrp = yes; then
Index: Src/params.c
===================================================================
RCS file: /cvs/zsh/zsh/Src/params.c,v
retrieving revision 1.1.1.48
diff -u -r1.1.1.48 params.c
--- Src/params.c	2000/03/14 08:17:02	1.1.1.48
+++ Src/params.c	2000/03/25 15:34:25
@@ -453,6 +453,10 @@
     char **new_environ, **envp, **envp2, **sigptr, **t;
     char buf[50], *str, *iname;
     int num_env, oae = opts[ALLEXPORT];
+#ifdef HAVE_UNAME
+    struct utsname unamebuf;
+    char *machinebuf;
+#endif
 
     paramtab = realparamtab = newparamtable(151, "paramtab");
 
@@ -538,7 +542,17 @@
 
     /* Add the standard non-special parameters */
     set_pwd_env();
+#ifdef HAVE_UNAME
+    if(uname(&unamebuf)) setsparam("MACHTYPE", ztrdup(MACHTYPE));
+    else
+    {
+       machinebuf = ztrdup(unamebuf.machine);
+       setsparam("MACHTYPE", machinebuf);
+    }
+	
+#else
     setsparam("MACHTYPE", ztrdup(MACHTYPE));
+#endif
     setsparam("OSTYPE", ztrdup(OSTYPE));
     setsparam("TTY", ztrdup(ttystrname));
     setsparam("VENDOR", ztrdup(VENDOR));

Re: PATCH: 3.1.6-dev-20: runtime determination of MACHTYPE

[Bart Schaefer]

On Mar 25, 10:40am, Clint Adams wrote:
} Subject: PATCH: 3.1.6-dev-20: runtime determination of MACHTYPE
}
} This patch allows zsh to determine MACHTYPE at run-time, rather
} than from the configure results of the build-machine, assuming
} uname(2) is available.

My only issue with this is that it means MACHTYPE can no longer be
used as an indicator of what features are compiled into zsh.  Maybe
it never could, though ...

(Off-topic aside:

zagzig[102] uname -snrvm
Linux zagzig 2.0.36 #1 Tue Oct 13 22:17:11 EDT 1998 i686
zagzig[103] uname -a
Linux zagzig 2.0.36 #1 Tue Oct 13 22:17:11 EDT 1998 i686 unknown

Where'd that extra "unknown" come from?)

-- 
Bart Schaefer                                 Brass Lantern Enterprises
http://www.well.com/user/barts              http://www.brasslantern.com

Re: PATCH: 3.1.6-dev-20: runtime determination of MACHTYPE

[Thomas Köhler]

On Sat, Mar 25, 2000 at 06:15:53PM +0100,
Bart Schaefer <schaefer@candle.brasslantern.com> wrote:
> 
> (Off-topic aside:
> 
> zagzig[102] uname -snrvm
> Linux zagzig 2.0.36 #1 Tue Oct 13 22:17:11 EDT 1998 i686
> zagzig[103] uname -a
> Linux zagzig 2.0.36 #1 Tue Oct 13 22:17:11 EDT 1998 i686 unknown
> 
> Where'd that extra "unknown" come from?)

       -p, --processor
                     print the host processor type

510 jean-luc@picard (ttypts/8) ~> uname -snrvmp ; uname -a
Linux picard 2.2.14 #3 Fri Mar 24 22:02:16 CET 2000 i686 unknown
Linux picard 2.2.14 #3 Fri Mar 24 22:02:16 CET 2000 i686 unknown


CU,
Thomas

-- 
 Thomas Köhler Email:   jean-luc@picard.franken.de     | LCARS - Linux
     <><        WWW:     http://jeanluc-picard.de      | for Computers
                IRC:             jeanluc               | on All Real
               PGP public key available from Homepage! | Starships

Re: PATCH: 3.1.6-dev-20: runtime determination of MACHTYPE

[Zefram]

Clint Adams wrote:
>This patch allows zsh to determine MACHTYPE at run-time, rather
>than from the configure results of the build-machine, assuming
>uname(2) is available.

It's not that easy.  Look at config.guess: $MACHTYPE is not always
the same as `uname -m`.  Leave $MACHTYPE being compiled in as it was.
If you want access to the runtime uname strings without forking off a
uname process, invent a new special parameter.

-zefram

Re: PATCH: 3.1.6-dev-20: runtime determination of MACHTYPE

[Clint Adams]

> It's not that easy.  Look at config.guess: $MACHTYPE is not always
> the same as `uname -m`.  Leave $MACHTYPE being compiled in as it was.
> If you want access to the runtime uname strings without forking off a
> uname process, invent a new special parameter.

The behavior of config.guess is a bit inconsistent, and this description
is a little vague.

       MACHTYPE
              The machine type (microprocessor class  or  machine
              model), as determined at compile time.


What was the original purpose of the parameter?  Seems to me that
`uname -m`, `uname -p`, and the output of arch(1) are often a stretch
from what one might infer from their descriptions, anyway, not to
mention inconsistent, but if MACHTYPE is set to sparc without regard
for whether I'm on a SuperSPARC or an UltraSPARC, whether I'm running
Solaris or Linux, then why differentiate between types of Alpha or x86?
Especially if the same chip will be i686 under Linux and i386 under FreeBSD?

The problem's scope is really beyond zsh, but if a parameter is compiled
in, it should be a generic "CPU architecture" type (e.g. sparc, ix86/i386,
alpha, m68k, &c.), and if it's defined at runtime, it should be more specific.

So I'm fine with adding a new parameter and keeping MACHTYPE static,
but in that case I think that MACHTYPE should become more generic.
Anyone disagree?

Re: PATCH: 3.1.6-dev-20: runtime determination of MACHTYPE

[Zefram]

Clint Adams wrote:
>What was the original purpose of the parameter?

The purpose is to record the GNU-style system identification string that
was used when configuring zsh.  The full system identification string is
"$MACHTYPE-$VENDOR-$OSTYPE".  Note that it is about the zsh configuration,
*not* the system on which zsh is running.

These three parameters should all be left as they are; they should be
directly comparable to the output of config.{guess,sub}.

-zefram