CONF(5)

πŸ’– CONF(5) β€” LAM node process schema πŸ’–

ok so bestie, welcome to conf(5) from the LAM FILE FORMATS corner of the manual. this one's niche, but we're gonna make it cute. πŸŽ€


✨ NAME ✨

conf β€” LAM node process schema


🌸 DESCRIPTION 🌸

okay so real talk first: most LAM/MPI users can fully disregard this page. it's not for you, and that's fine. no shade. πŸ’…

A process schema is basically a little list of the system processes that are gonna make up the LAM environment on one particular node. So it's the blueprint of who shows up to the party on that machine. 🫢

LAM developers tho? they're obsessed with process schemata, because they're genuinely so useful for debugging and for generating custom systems. main character tool fr.

Separate default configuration files are normally used for booting either the single-daemon version (conf.lam) or the external-servers version (conf.otb). The single-daemon version is the default β€” that's the one you get unless you say otherwise. The external-servers version is typically what LAM developers reach for when they're debugging LAM services. πŸ”

The -c option to hboot(1) lets you specify the file name of a custom process schema. And heads up: this capability is not available with lamboot(1). so don't try it there, bestie.

Application programs can be booted with the LAM environment by including the program name in the process schema. yes, you can just... put it in there. iconic. ✨


πŸ¦‹ STRUCTURE AND SYNTAX πŸ¦‹

The process schema grammar defines three types of statements: comments, processes, and options. three flavors, one vibe check. 🌈

Comments begin with # and terminate with a newline. short and sweet.

Process statements consist of a filename, command line arguments, and possibly options local to the process. The command line arguments are passed to the process when it is started. The process options are used by the booting tools before starting the process. (so like, args = for the process, options = for the booting tools. two different audiences. iykyk.)

Filenames may include application programs and any of the system processes listed below. here's the whole squad: πŸ‘‘

  • bforward β€” bufferd helper, forwards remote messages.
  • bufferd β€” creates, kills, sweeps, and states buffers.
  • dli_inet β€” sends data on network connections.
  • dlo_inet β€” receives data from network connections.
  • echod β€” echoes messages; can be used to test nodes and links.
  • filed β€” serves file access.
  • flatd β€” provides symbolic access to node memory.
  • iod β€” handles stdio data of processes.
  • kenyad β€” controls and monitors processes.
  • kernel β€” coordinates message passing.
  • lamd β€” single-daemon version of all servers excluding ledd and mtvd.
  • ledd β€” controls LEDs.
  • loadd β€” loads executable files onto nodes.
  • mtvd β€” controls a pixel map display.
  • router β€” maintains routing tables.
  • traced β€” collects and transports trace data.
⚠️ Processes are started in the order given in the process schema, and for LAM, the order is important. The kernel must be first. like, no negotiating. kernel first or it's over. πŸ’€

Process options are placed inside braces {} following the command line arguments. Process options consist of a keyword followed by an assigned value in parentheses. Options that are not explicitly given have default settings.

Here's the tea on scoping:

  • Options inside braces in process statements apply only to that process.
  • Options outside process statements apply to all processes that appear later in the process schema, unless locally overridden. (global girlies, but local can always overrule them. πŸ’…)

All the options are listed below:

  • inet_topo β€” a string of dli_inet or lamd options, global only, default null
  • rtr_topo β€” a string of router options, global only, default null
  • delay β€” waiting time in seconds after process boot, default 0

The inet_topo and rtr_topo options can be overridden from the command line of hboot(1) using the -I and -R options respectively. πŸŽ€


πŸ”₯ EXAMPLES πŸ”₯

Following are example process schemata. The first file is used for an OTB node in LAM:

##
## typical LAM process schemata
##

lamd $inet_topo

The second file is used by LAM developers to control each server as an independent process, typically during debugging:

##
## external-servers LAM process schemata
##

##
## The kernel is listed first.
##
kernel $delay

##
## daemons
##
router
kenyad
dli_inet $inet_topo
dlo_inet
bufferd
bforward
loadd
echod
flatd
filed
traced
iod

see how kernel is sitting right at the top? exactly as the rules demand. periodt. πŸ’–


πŸŽ€ FILES πŸŽ€

  • $LAMHOME/etc/lam-conf.lamd β€” default LAM node process schema, where $LAMHOME is the installation directory
  • $LAMHOME/etc/lam-conf.separate β€” example external-servers node process schema used when debugging LAM

πŸ’œ SEE ALSO πŸ’œ


ok that's the whole page, bestie!! this one's from LAM 7.1.4, dated July, 2007 β€” so like, vintage, but make it slay. πŸ’…βœ¨ go forth and schema responsibly, and remember: kernel goes first. always. πŸ«ΆπŸŽ€