dlm@lhdsy1.chevron.com (Dennis L. Malefyt) (05/08/91)
I am posting this in the hope that I will not have to create and
maintain a host_type database.
Situation: we have DECstations, Sparcs, Appollos, RS6000, Cray XMP,
MasPar, SGI Iris4D's, Macs, VAXstations, HP's ... and on and on.
Problem: we want a unique and simple way for a user/developper to
determine what type of machine he/she is on. What we are interested in
is the binary compatibility, not the model number, amount of RAM, etc...
of a particular machine.
Solution: is two-folded.
a) we need a database of significant names
b) we need a mechanism to get the appropriate name.
What already exists: tcsh has an environmental variable called HOSTTYPE.
I am including as few lines of the latest list of tcsh HOSTTYPES, as
well as some text which accompanies it:
start:
19. NEW ENVIRONMENT AND SHELL VARIABLES
On startup, tcsh now automatically initializes the
environment variable HOST to the name of the machine that it is
running on. It does this by doing a gethostname(2)
system call, and setting HOST to the result.
Tcsh also initializes the environment variable HOSTTYPE to a
symbolic name for the type of computer that it is running
on. The current possible values are:
ns32000 an NS32000 CPU machine
next a NeXT computer
aix370 an IBM 370, running aix
alliant an Alliant FX series
...
decstation a DecStation XXXX
gould-np1 a Gould NP1
hp300 an HP 9000, series 300, running mtXinu
hp800 an HP 9000, series 800, running mtXinu
...
end.
The problem with tcsh is that it does not contain a complete list of all
possible hardware, cray being one example.
Also, we want the solution to be shell independent, not ala tcsh. Tcsh
is used here just for the (incomplete) list of names it provides.
Other solutions we have looked at: we have looked at cpp but it is not
guaranteed to work on its own and one would have to look at more than
one keyword to figure out what is what. We also have looked at what some
platforms offer: DEC offers the command named "machine" but it answers
mips. Oh well, so much for that, since the SGI can also say mips too and
they are not binary compatible... Not to mention Sony, MIPS
themselves...
Now for the big question: Are we the first to look at this problem (I
doubt it ...) and what are the solutions that were found?
We could develop our own database of names but if one already exists and
is maintained by certain group, then this is one less standard that we
have to worry about!
Again, this is a two-question thing: there is a) the topic of "what name
to use to identify a machine"?, and b) "how does the user get the name
for his/her machine"?
We are thinking of using a command named "hosttype" which would return
the appropriate string. Since we need to be portable, is this command
already used in any UNIX?
I welcome any input. Thank you for your attention.
--
+--------------------------------------------------------------+
| Dennis Malefyt Internet: dlm@chevron.com |
| Chevron Information Technology Co. Tel: (213) 694-7531 |
| La Habra, California 90633-0446 Fax: (213) 694-7709 | karl.kleinpaste@osc.edu (05/08/91)
At OSU CIS, all officially-supported machines have a file /etc/sysinfo which contains various bits of system-specific information, e.g., pyr:/vmunix:bsd4.3:osx4.4c:/bin/hostname which in general reads as architecture:/KernelName:WhatItLooksLike:WhatVendorCallsIt:HowToGetHostname This is trivially parsed in everyone's .cshrc files so you can then move on from there. We set this up over 3 years ago when the department was first beginning to purchase large numbers of workstations and other disparate hardware. It works very well and is only a minor maintenance headache. Most discless Sun clients, for example, have only a symlink /etc/sysinfo -> /usr/local/sysinfo and then those clients which break the "pattern" for that server have their own, real /etc/sysinfo. --karl
verber@pacific.mps.ohio-state.edu (Mark Verber) (05/08/91)
SunOS and various other flavors of UNIX have the 'arch' command. A simple solution is to add a version of 'arch' for platforms that don't have it. For example, I have added /bin/arch to my DECstations that says simply: #!/bin/sh echo "pmax" exit 0 Ohio State Univ. Computer Science Dept has a file called /etc/sysinfo that had useful bits of information such are archtype, kernel's name, derivation of the OS, how to get the hostname, etc. We had a shell script that would parse this file and set appropriate environment variables. An example of a /etc/sysinfo: sun4:/vmunix:bsd4.2:sunos4.1:/bin/hostname cheers, mark
daniel@island.COM (Daniel Smith "innovation, not litigation...") (05/10/91)
I posted this a while back, you can use it as a start... you
just need to figure out what is different about a dec or whatever, and
add the appropriate lines. It's derived from the sun "arch" command.
It's better to have each machine have some sort of database in one place,
like Karl K. mentioned, but if you're dealing with "stock" systems, then
you need to take this approach (query after query...)
Daniel
#! /bin/sh
#
# whicharch - what machine am I on?
# daniel@island.com (Please send me any extensions to this)
#
if [ -f /bin/sun4c ] && /bin/sun4c; then
echo sun4
elif [ -f /bin/sun4 ] && /bin/sun4; then
echo sun4
elif [ -f /bin/sun3 ] && /bin/sun3; then
echo sun3
elif [ -f /bin/sun3x ] && /bin/sun3x; then
echo sun3
elif [ -f /bin/sun386 ] && /bin/sun386; then
echo sun386
elif [ -f /bin/sun2 ] && /bin/sun2; then
echo sun2
elif [ -f /bin/hp9000s200 ] && /bin/hp9000s200; then
echo hp300
elif [ -f /bin/hp9000s300 ] && /bin/hp9000s300; then
echo hp300
elif [ -f /bin/hp9000s500 ] && /bin/hp9000s500; then
echo hp500
elif [ -f /bin/hp9000s800 ] && /bin/hp9000s800; then
echo hp800
elif [ -f /bin/4d ] && /bin/4d; then
echo sgi
elif [ -f /bin/i286 ] && /bin/i286; then
echo 286
elif [ -f /bin/i386 ] && /bin/i386; then
echo 386
elif [ -f /bin/i486 ] && /bin/i486; then
echo 486
elif [ -f /bin/i586 ] && /bin/i586; then
echo 586
elif [ -f /usr/bin/X11/aixterm ] ; then
echo ibm
elif [ -f /com/lvolfs ] ; then
echo ${NODETYPE+apollo}
else
echo unknown
fi
--
daniel@island.com Daniel Smith, Island Graphics, (415) 491 0765 x 250(w)
daniel@world.std.com 4000 CivicCenterDrive SanRafael MarinCounty CA 94903
dansmith@well.sf.ca.us Fax: 491 0402 Disclaimer: Hey, I wrote it, not IG!
falling/yes I'm falling/and she keeps calling/me back again - IJSaF, Beatlesclewis@ferret.ocunix.on.ca (Chris Lewis) (05/10/91)
In article <858@lhdsy1.chevron.com> dlm@lhdsy1.chevron.com (Dennis L. Malefyt) writes: >Problem: we want a unique and simple way for a user/developper to >determine what type of machine he/she is on. What we are interested in >is the binary compatibility, not the model number, amount of RAM, etc... >of a particular machine. >Solution: is two-folded. > a) we need a database of significant names > b) we need a mechanism to get the appropriate name. You have to consider two scenarios: if the machines are under your control, you'd be best off creating a file (such as was mentioned elsewhere) that contains your configuration/compilation keys. On the other hand, if they aren't under your control (eg: your software has to build on "virgin" systems that you don't support), you can do something like we did: We have some software that automatically compiles itself "correctly" on at least 30 platforms (from archaic Xenix systems thru many flavors of System III, V, AIXes, Irises and BSD-derived machines). The software is inherently rather "systemy", so there are a LOT of differences we have to intuit. I implemented a shell script that attempts to figger out what machine the software is being built on, and it places the name into a file, plus occasionally other special flags. The makefile encorporates this in the build procedure as a -D<machinename>, and the main .h file has a lot of ifdef's. Rather than try to identify commonality amongst different platforms, we simply key on the machine type on the places where dependencies arise - both in C code, and in shell scripts. There is, unfortunately, no common method to do this. The shell script looks at the following things: 1) Many systems have "/bin/true" and "/bin/false" linked to several "machine type names". Ie: on my 3b1: 85 -rwxr-xr-x 2 bin bin 33 Jan 1 1970 mc68k 85 -rwxr-xr-x 2 bin bin 33 Jan 1 1970 true 76 -rwxr-xr-x 5 bin bin 42 Jan 1 1970 false 76 -rwxr-xr-x 5 bin bin 42 Jan 1 1970 pdp11 76 -rwxr-xr-x 5 bin bin 42 Jan 1 1970 u370 76 -rwxr-xr-x 5 bin bin 42 Jan 1 1970 u3b 76 -rwxr-xr-x 5 bin bin 42 Jan 1 1970 vax I have a loop like this: for i in mc68k pdp11 u370 u3b vax sun3 sun4 mips 4d do # arg! Old Bourne shells don't support -x! if -f /bin/$i then if /bin/$i then machinetype=$i break fi fi done 2) Many systems also have a "uname" that you can intuit a type from (this is how we detect AIX in it's three main flavors) 3) Some machines have files that are unique to them. Examples: - Dynix (Sequent) has it's kernel in "/dynix". - 3b1's have a /etc/lddrv directory (but so does Unisys's 386 platforms, but we can disambiguate by other features) - Most SVR3 386 platforms have /etc/conf etc. - NCR Towers have /etc/RELDEF and /etc/SYSIDENT You have to validate your software on each platform you port to, and at that time you can figger out how to disambiguate it from other flavors for autobuilds. This works well enough for us that we can uux a tar image of the source tree to a remote system and have it build and install correctly without human access to the machine. Without having to know what platform we're uux'ing it at. -- Chris Lewis, Phone: (613) 832-0541, Domain: clewis@ferret.ocunix.on.ca UUCP: ...!cunews!latour!ecicrl!clewis; Ferret Mailing List: ferret-request@eci386; Psroff (not Adobe Transcript) enquiries: psroff-request@eci386 or Canada 416-832-0541. Psroff 3.0 in c.s.u soon!
guy@auspex.auspex.com (Guy Harris) (05/16/91)
>elif [ -f /bin/i286 ] && /bin/i286; then > echo 286 >elif [ -f /bin/i386 ] && /bin/i386; then > echo 386 >elif [ -f /bin/i486 ] && /bin/i486; then > echo 486 >elif [ -f /bin/i586 ] && /bin/i586; then > echo 586 Are there *really* commands for "i486" and "i586"? I wouldn't be at all surprised if System V releases for 386's, 486's, and up weren't mostly-generic "386-and-up" systems, such that only some small part of the kernel code cared which of the implementations of the 386-and-up architecture they were running on. Also, I think the command for the 286 is called "iapx286" or maybe "iAPX286".
ericm@ibmpa.awdpa.ibm.com (Eric Murray) (05/16/91)
In article <4035@island.COM> daniel@island.COM (Daniel Smith "innovation, not litigation...") writes: > >#! /bin/sh ># ># whicharch - what machine am I on? ># daniel@island.com (Please send me any extensions to this) ># [...] Here's how to tell the various IBM UNIX-like systems apart: # Determine the system type. Set ${sys} to one of the # following depending on which operating system is running. # # rt_bsd: 4.3 BSD on RT # aix_22: AIX 2.* on RT # aix_11: AIX 1.1 or AIX 1.2 on PS/2 # aix_31: AIX 3.1 on RISC 6000 # # if [ -f /unix ] then if [ -d /vrm ] then sys=aix_22 else if [ -d /etc/security ] then sys=aix_31 else sys=aix_11 fi fi else if [ -f /vmunix ] then sys=rt_bsd else sys=unknown fi fi eric murray ericm@angst.awdpa.ibm.com ericm@ibminet.awdpa.ibm.com the lawyers make me say: this posting doesn't represent official ibm policy
daniel@world.std.com (Daniel Smith) (05/16/91)
In <7844@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >[from my original followup] > >elif [ -f /bin/i486 ] && /bin/i486; then > > echo 486 > >elif [ -f /bin/i586 ] && /bin/i586; then > > echo 586 > Are there *really* commands for "i486" and "i586"? I wouldn't be at all > surprised if System V releases for 386's, 486's, and up weren't Probably not yet, but I decided not to let that get in the way :-) > Also, I think the command for the 286 is called "iapx286" or maybe > "iAPX286". Oh, ok. I was working off of what I was seeing on a Sun, but I did not look closely enough. Interesting that Sun would have a /bin/i386 and a /bin/iAPX286; seems like it should go one way or another. The basic gist of my adapted "arch" script was: find some file unique to a machine and do some guesswork. Hope to see some additions to it so that we can all benefit. Daniel -- daniel@island.com .....Daniel Smith, Island Graphics, (415) 491 0765 x 250(w) daniel@world.std.com ...4000 CivicCenterDrive SanRafael MarinCounty CA 94903 dansmith@well.sf.ca.us .I must write this, or Island will take away my coffee. Could we continue with the petty bickering? I find it most intriguing-Data:TNG
rowe@cme.nist.gov (Walter Rowe) (05/16/91)
The ``Configure'' script distributed with PERL has some really crafty mechanisms for determining what type of machine you are on. It uses a combination of unique files and/or the program /bin/uname which some system support (I know SunOS does). wpr --- Walter Rowe rowe@cme.nist.gov ...!uunet!cme-durer!rowe National Institute of Standards and Technology / U.S. Department of Commerce
bill@bilver.uucp (Bill Vermillion) (05/17/91)
In article <7844@auspex.auspex.com> guy@auspex.auspex.com (Guy Harris) writes: >>elif [ -f /bin/i286 ] && /bin/i286; then >> echo 286 > >Are there *really* commands for "i486" and "i586"? ... .... >Also, I think the command for the 286 is called "iapx286" or maybe >"iAPX286". Well on my SysV.3.2 (ESIX), the i286 is linked with iAPX286, along with links to mc68k, pdp11, u370, u3b, u3b15, u3b2, u3b5, and most importantly, false. And it's not a command - just a file that returns true or false. -- Bill Vermillion - UUCP: ...!tarpit!bilver!bill : bill@bilver.UUCP
chip@tct.com (Chip Salzenberg) (05/20/91)
According to rowe@cme.nist.gov (Walter Rowe): >The ``Configure'' script distributed with PERL has some really crafty >mechanisms for determining what type of machine you are on. When it is run on a system that is subtly different from one it knows, Configure comes up with lots of plausible but wrong answers. Configure's mechanism -- create config.sh, then run *.SH, which are shell scripts that create Makefile etc. based on config.sh -- is great. Its guessing-game ass_u_me hacks, though, are atrocious. -- Brand X Industries Custodial, Refurbishing and Containment Service: When You Never, Ever Want To See It Again [tm] Chip Salzenberg <chip@tct.com>, <uunet!pdn!tct!chip>