blarsen@spider.uio.no (Bjorn Larsen) (05/23/91)
We are writing a daemon that should execute on a number of different UNIX platforms. It should fetch performance information about the running system. We want to make this program as portable as possible, possibly by dividing it into one generic part and one system-specific part. The UNIX variants that we want to run this daemon on includes SunOS, Ultrix, OSF/1, SVR4, SVR3.2, Convex UNIX, SCO UNIX, and possibly others. I'm looking for advice on the best way to handle this. Does there exist a standard interface for retreiving such information? I've heard rumors that there exists a kmem-access library for BSD4.3. Would it be feasible to start with this library and port it or reimplement it on the abovementioned platforms in such a way that the call interface remains identical on all platforms? If this is the case, I assume that we would want to use the kmem library routines as the call interface between the generic and system specific parts of the deamon, and attempt to make everything above the kmem library portable. I'm generally ignorant about this topic; for all I know there might be inherent differences in the way the different UNIX variants store data in kmem that makes this approach a dead end. If so, what should we do? Seeking enlightenment, Bjorn.Larsen@usit.uio.no "Specialization is for insects" University Centre for Information Technology - Lazarus Long University of Oslo, Norway
cgy@cs.brown.edu (Curtis Yarvin) (05/23/91)
In article <BLARSEN.91May23060050@spider.uio.no> Bjorn.Larsen@usit.uio.no writes: > >We are writing a daemon that should execute on a number of different >UNIX platforms. It should fetch performance information about the >running system. > >We want to make this program as portable as possible, possibly by >dividing it into one generic part and one system-specific part. > >The UNIX variants that we want to run this daemon on includes SunOS, >Ultrix, OSF/1, SVR4, SVR3.2, Convex UNIX, SCO UNIX, and possibly >others. Yow. >I'm looking for advice on the best way to handle this. Does there >exist a standard interface for retreiving such information? >I've heard rumors that there exists a kmem-access library for BSD4.3. It should never have had to exist in the first place; but there is. -lkvm will link with it. But it needs a symbol to find. It can read the data corresponding to a kernel name or a kernel virtual address. But bear in mind that when we say "symbol," we're talking about internal kernel variables. This stuff is by definition unportable. Your best bet is to make a very explicit split between the portable and nonportable modules of the monitor daemon. Curtis
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (05/26/91)
In article <BLARSEN.91May23060050@spider.uio.no> Bjorn.Larsen@usit.uio.no writes: [ wants to put together a kernel-reading program ] > We want to make this program as portable as possible, possibly by > dividing it into one generic part and one system-specific part. That's always a good idea. > The UNIX variants that we want to run this daemon on includes SunOS, > Ultrix, OSF/1, SVR4, SVR3.2, Convex UNIX, SCO UNIX, and possibly > others. My kstuff package runs under SunOS, Ultrix, Convex UNIX, and some others; it should be easy to port to OSF/1, slightly less easy to port to SVR4, and difficult to port to various older System V machines. > I've heard rumors that there exists a kmem-access library for BSD4.3. > Would it be feasible to start with this library and port it or > reimplement it on the abovementioned platforms in such a way that the > call interface remains identical on all platforms? If those rumors are about kstuff, then yes, it should be possible to port while preserving the same interface. kstuff 0.18 was just posted to alt.sources and is available via anonymous ftp to 128.122.128.22 in pub/hier/kstuff:/18. ---Dan
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) (05/26/91)
In article <76560@brunix.UUCP> cgy@cs.brown.edu (Curtis Yarvin) writes: > >I've heard rumors that there exists a kmem-access library for BSD4.3. > It should never have had to exist in the first place; but there is. -lkvm > will link with it. -lkvm is a Sun-ism. You can get almost all the same functions out of the much more portable kmem and getuser libraries inside my kstuff package. > But bear in > mind that when we say "symbol," we're talking about internal kernel > variables. This stuff is by definition unportable. The main point of kstuff is to provide higher-level, portable interfaces to most of the useful kernel symbols. ---Dan
richard@locus.com (Richard M. Mathews) (05/30/91)
cgy@cs.brown.edu (Curtis Yarvin) writes: >Your best bet is to make a very explicit split between the portable and >nonportable modules of the monitor daemon. I might even go farther than that. I'd have a completely portable frontend which only understands high level concepts like "get me the performance data." For many systems, there will be a large amount of common code in the non-portable backend; so I'd split it into 2 parts -- a semi-portable piece which works with most systems and a completely system-dependent piece which deals with each system's idiosyncrasies (such as the names of the kernel variables). For a few systems, such as those which don't let you directly read kmem at all, both of these pieces would be replaced by a system-dependent module. On the majority of systems, however, the semi-portable piece would be usable. Richard M. Mathews Lietuva laisva = Free Lithuania richard@locus.com Brivu Latviju = Free Latvia lcc!richard@seas.ucla.edu Eesti vabaks = Free Estonia ...!{uunet|ucla-se|turnkey}!lcc!richard
scottl@convergent.com (Scott Lurndal) (05/30/91)
In article <11942:May2521:33:5791@kramden.acf.nyu.edu>, brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: |> In article <BLARSEN.91May23060050@spider.uio.no> Bjorn.Larsen@usit.uio.no writes: |> [ wants to put together a kernel-reading program ] |> > We want to make this program as portable as possible, possibly by |> > dividing it into one generic part and one system-specific part. |> |> That's always a good idea. |> |> > The UNIX variants that we want to run this daemon on includes SunOS, |> > Ultrix, OSF/1, SVR4, SVR3.2, Convex UNIX, SCO UNIX, and possibly |> > others. |> |> My kstuff package runs under SunOS, Ultrix, Convex UNIX, and some |> others; it should be easy to port to OSF/1, slightly less easy to port |> to SVR4, and difficult to port to various older System V machines. |> I daresay impossible to some SVR4 and SVR3.2 implementations. |> > I've heard rumors that there exists a kmem-access library for BSD4.3. |> > Would it be feasible to start with this library and port it or |> > reimplement it on the abovementioned platforms in such a way that the |> > call interface remains identical on all platforms? |> |> If those rumors are about kstuff, then yes, it should be possible to |> port while preserving the same interface. kstuff 0.18 was just posted to |> alt.sources and is available via anonymous ftp to 128.122.128.22 in |> pub/hier/kstuff:/18. |> |> ---Dan Since there is no standards requirement for /dev/kmem (and our implementation of SVR4.0 for the 88100 does not even have one), how portable is any library that attempts to extract data from an operating system? To be called unix, you must provide certain functionality (defined by the SVID and perhaps XPG3). You do not have to internally look anything like unix as provided by AT&T (System V) or Berkeley (BSD 4.x); certainly you don't have to use the same symbol names! A [more portable] source for perf information on sysV systems would be sadc(1) which writes some binary information to stdout concerning system performance (this is the information used by sar(1) for reports). Scott Lurndal scottl@convergent.com UNISYS Open Systems Group uunet!pyramid!ctnews!scottl San Jose, Ca