/var/inst documentation: Difference between revisions

From TechPubs Wiki

initial commit
 
(No difference)

Latest revision as of 04:12, 21 October 2025

Overview

Each file under /var/inst is a product definition — an installed-package record created by the IRIX inst subsystem. These files are used by inst, versions, and internal libinst.so routines to reconstruct the system inventory.

They are plain, uncompressed data streams comprising NUL-terminated ASCII records, which describe subsystems, components, conditions, paths, and metadata.

General Structure

Element Type Notes
Header Record Fixed ASCII string Always begins with pd001VxxxP00. Vxxx encodes the inst database version (e.g. V630 = IRIX 6.3, V650 = IRIX 6.5).
Body Records Variable-length, NUL-terminated strings Contain subsystem, component, description, condition, path information.
Footer / Terminator EOF Files end at EOF; no explicit checksum or final sentinel required.

Encoding: ASCII (7-bit) Delimiter: NUL (\0) Compression: None

Common Record Types (Observed)

Token / Prefix Likely Meaning Example
(no prefix) Product name or subsystem identifier sgi_apache, x_eoe
  • | Human-readable description | +SGI Web Server based on Apache, 1.3.35 ) | Source directory or source-related tag | )d/usr/people/.../dist $, ', & | UI label or alternate descriptor | $SGI Web Server Release Notes, 1.3.35 patch*, maint* | Patch / maintenance relationships | patch*sgi_apache_sw T/ | Target installation path | T/var/sgi_apache/server/share/... d | Build or distribution tag | d10.0.0.206:love.6530.app P_ | Timestamp pair (installation/build timestamps) | P1147443119_1279655720 Conditionals | !noship, !!noship, !noship && DEV, || | Installation conditions / policy expressions Architecture markers | LE, 8wu, OT, NT, etc. | Platform/build variant markers (exact semantics TBD)

Logical Hierarchy

Although stored sequentially, the file encodes a logical tree:

PRODUCT ├─ SUBSYSTEM │ ├─ COMPONENT │ ├─ PATHS / DOCS │ ├─ PATCH / MAINT relationships │ └─ CONDITIONS └─ GLOBAL METADATA (timestamps, build tags)

Parsing Heuristics

  1. Read the first token; it must match the header pd001VxxxP00.
  2. Iterate NUL-delimited ASCII strings in order:
    • Short lowercase tokens → subsystem/component names.
    • Tokens beginning with +, &, $, ' → descriptions/labels.
    • Tokens beginning with patch* / maint* → relationships.
    • Tokens beginning with T/ or containing /usr/, /var/, /lib/ → paths.
    • Tokens containing love. or d<version> → build/installer annotations.
  3. Group contiguous tokens into one logical block until the next subsystem name is encountered.

Header Versions (Observed)

Header IRIX Family
pd001V530P00 IRIX 5.3
pd001V630P00 IRIX 6.3
pd001V650P00 IRIX 6.5

Example (Simplified)

pd001V650P00 x_eoe &X11 Execution Environment, 6.5.30 d10.0.0.206:love.6530.app P123456789_987654321 books &X11 Documentation patchx_eoe_books maintx_eoe_books x_eoe_sw64 &X11 64-bit Executables

Observations & Notes

  • Files are mostly human-readable ASCII when examined as strings.
  • Fields like descriptions may appear more than once (UI label vs. internal label).
  • Repeated binary-looking sequences (e.g. control bytes) appear between string groups; these are likely structural delimiters or metadata bytes.
  • The love.* token is used by community installers (miniroot/overlay markers); treat it as an opaque distribution label unless confirmed otherwise.

Unknowns / Open Research

  • Exact semantics for architecture/variant tokens like 8wu, LE, OT, NT.
  • Full truth table for conditional expressions (!noship, !!noship, and boolean combos).
  • Precise internal representation used by libinst.so — RE of libinst would confirm concrete struct layouts.
  • Relationship and synchronization logic between /var/inst product files and any central index (e.g., /var/inst/installed if present).

Recommended Next Steps

  1. Collect /var/inst files from IRIX 6.2–6.5 and diff identical products across versions.
  2. Cross-validate parsed results against versions -v and inst outputs on IRIX (when possible).
  3. RE libinst.so (symbols like inst_read_*) to confirm struct field types and ordering.
  4. Implement a minimal C parser (library) that:
    • Iterates NUL-delimited strings
    • Classifies tokens by the heuristics above
    • Builds an in-memory tree (PRODUCT → SUBSYSTEM → COMPONENT) for versions-like queries

Goal

Produce a portable C library to:

  • Read /var/inst product files,
  • Reconstruct their logical hierarchy,
  • Provide an API for versions-style checks and comparisons on non-IRIX hosts.

This document is a living draft. Contributions and empirical data (dumps, offsets, diffs) are encouraged to refine and finalize the format.