anselmo-ed@cs.yale.edu (Ed Anselmo) (10/02/90)
Is there an appropriate pre-processor symbol for UMAX 4.3, akin to
sun on Suns and sequent on Sequents?
I recently built X11R4 from the MIT sources for our Multimax and ended
up adding "umax" to the imake defines in mit/config/imakedep.h.
Did I miss some obvious choice for a cpp #define?
BTW, the build seemed to be successful, apart from having to hack the
xload sources to use inq_stats().
--
Ed Anselmo anselmo-ed@cs.yale.edu {harvard,cmcl2}!yale!anselmo-edjrm@stegosaur.cis.ohio-state.edu (John R. Mudd) (10/03/90)
In article <26458@cs.yale.edu> anselmo-ed@cs.yale.edu (Ed Anselmo) writes: >Is there an appropriate pre-processor symbol for UMAX 4.3, akin to >sun on Suns and sequent on Sequents? The following symbols are defined for the approproiate processor cards: ns32032 (DPC), ns32332 (APC), and ns32532 (XPC) It's on pg 2-11 of the UMAX 4.3 C Programming Guide. >BTW, the build seemed to be successful, apart from having to hack the >xload sources to use inq_stats(). You too, eh? Since the UMAX kernel doesn't seem to define "_avenrun", it'd be awfully nice for Encore to provide their users with a replacement for xload/get_load.c (hint hint). My version of xload that uses inq_stats() seems to have really lousy resolution, which means the graphic load meter is stair-stepped. Reminds me a lot of TRS80 graphics. :-) ... John .......................................................................... John R. Mudd jrm@cis.ohio-state.edu Department of Computer and Information Science, The Ohio State University 2036 Neil Avenue, Columbus, Ohio, USA 43210-1277 +1 614 292 7161
anselmo-ed@cs.yale.edu (Ed Anselmo) (10/03/90)
>>>>> On 2 Oct 90 20:34:13 GMT, jrm@stegosaur.cis.ohio-state.edu (John R. Mudd) said:
John> You too, eh? Since the UMAX kernel doesn't seem to define
John> "_avenrun", it'd be awfully nice for Encore to provide their
John> users with a replacement for xload/get_load.c (hint hint). My
John> version of xload that uses inq_stats() seems to have really
John> lousy resolution, which means the graphic load meter is
John> stair-stepped. Reminds me a lot of TRS80 graphics. :-)
The version I lifted from the GNU emacs etc/loadst.c works pretty
well. Diffs to the original get_load.c follow.
*** mit/clients/xload/get_load.c.orig Thu Dec 14 09:46:20 1989
--- mit/clients/xload/get_load.c Tue Oct 2 12:14:15 1990
***************
*** 80,85 ****
--- 80,98 ----
#define n_type n_value
#endif /* CRAY */
+ #ifdef umax
+ /*
+ * UMAX 4.2, which runs on the Encore Multimax multiprocessor, does not
+ * have a /dev/kmem. Information about the workings of the running kernel
+ * can be gathered with inq_stats system calls.
+ */
+ #include <machine/machparam.h>
+ #include <sys/syscall.h>
+ #include <inq_stats/statistics.h>
+ #include <inq_stats/procstats.h>
+ #include <inq_stats/sysstats.h>
+ #endif /* umax */
+
#ifdef sequent
#include <sys/vm.h>
#endif /* sequent */
***************
*** 106,111 ****
--- 119,161 ----
extern long lseek();
extern void exit();
+ #ifdef umax
+ void
+ GetLoadPoint( w, closure, call_data )
+ Widget w; /* unused */
+ XtPointer closure; /* unused */
+ XtPointer call_data; /* pointer to (double) return value */
+ {
+ int i, j;
+ double sum;
+ struct proc_summary proc_sum_data;
+ struct stat_descr proc_info;
+
+ proc_info.sd_next = NULL;
+ proc_info.sd_subsys = SUBSYS_PROC;
+ proc_info.sd_type = PROCTYPE_SUMMARY;
+ proc_info.sd_addr = (char *) &proc_sum_data;
+ proc_info.sd_size = sizeof (struct proc_summary);
+ proc_info.sd_sizeused = 0;
+
+ if (inq_stats (1, &proc_info) != 0 )
+ {
+ perror ("sysline proc summary inq_stats");
+ exit (1);
+ }
+ /*
+ * Generate current load average.
+ */
+ sum = 0;
+ for (i = proc_sum_data.ps_nrunidx, j = 0; j < 12; j++)
+ {
+ sum += proc_sum_data.ps_nrun[i];
+ if (--i < 0)
+ i = 179;
+ }
+ *(double *)call_data = sum /12;
+ }
+ #else /* not umax */
#if apollo
/* ARGSUSED */
void GetLoadPoint( w, closure, call_data )
***************
*** 401,406 ****
--- 451,457 ----
#endif /* LOADSTUB */
#endif /* KVM_ROUTINES */
#endif /* apollo */
+ #endif /* umax */
static xload_error(str1, str2)
char *str1, *str2;
--
Ed Anselmo anselmo-ed@cs.yale.edu {harvard,cmcl2}!yale!anselmo-edaglew@crhc.uiuc.edu (Andy Glew) (10/03/90)
>>Is there an appropriate pre-processor symbol for UMAX 4.3, akin to >>sun on Suns and sequent on Sequents? > >The following symbols are defined for the approproiate processor cards: > ns32032 (DPC), > ns32332 (APC), and > ns32532 (XPC) (1) There really should be an Encore specific define - it is possible that the code may have to be ported to another ns32x32 system, other than Encore's, which is incompatible. (Sure, there aren't all that many ns32x32 systems out there...) Really, should have OS revision level and version (4.3 vs SV) dependencies as well. (2) All of these symbols, sun, sequent, ns32032... should really have _s in front of their names, to avoid collisions with user variable names? (Ever have to port a program dealing with solar power?) -- Andy Glew, a-glew@uiuc.edu [get ph nameserver from uxc.cso.uiuc.edu:net/qi]
phil@eecs.nwu.edu (William LeFebvre) (10/03/90)
In article <AGLEW.90Oct2170036@dwarfs.crhc.uiuc.edu>, aglew@crhc.uiuc.edu (Andy Glew) writes: |>(2) All of these symbols, sun, sequent, ns32032... |> should really have _s in front of their names, |> to avoid collisions with user variable names? |> |> (Ever have to port a program dealing with solar power?) I was quite surprised the first time I tried to compile the BSD sources for lpr/lpd on a Sun. Turns out that Berkeley declared the sockaddr_un structure (for the Unix domain socket) to be called "sun". Sigh. I've complained before that these names should be in all upper case or something (like maybe preceded with _), but no one ever listens to me. At this point, inertia is against us. I think I'll start a computer manufacturing company and call it "index", or maybe just "i". :-) William LeFebvre Computing Facilities Manager and Analyst Department of Electrical Engineering and Computer Science Northwestern University <phil@eecs.nwu.edu>