On Sat, Mar 07, 2020 at 05:44:12PM +0100, Klemens Nanni wrote:
> Next to the IO device path to be used in ldom.conf we can also print the
> name which actually tells in human readable form what device we're
> looking at.
>
> Those names are printed in similar format by Solaris `ldm list-io' and
> directly match the the structure seen in the iLOM shell.
>
> $ doas ldomctl list-io
> PATH NAME
> /@400/@2/@0/@8 /SYS/MB/PCIE0
> /@500/@2/@0/@a /SYS/MB/PCIE1
> /@400/@2/@0/@4 /SYS/MB/PCIE2
> /@500/@2/@0/@6 /SYS/MB/PCIE3
> /@400/@2/@0/@0 /SYS/MB/PCIE4
> /@500/@2/@0/@0 /SYS/MB/PCIE5
> /@400/@1/@0/@8 /SYS/MB/PCIE6
> /@500/@1/@0/@6 /SYS/MB/PCIE7
> /@400/@1/@0/@c /SYS/MB/PCIE8
> /@500/@1/@0/@0 /SYS/MB/PCIE9
> /@400/@2/@0/@e /SYS/MB/SASHBA
> /@400/@1/@0/@4 /SYS/MB/NET0
> /@500/@1/@0/@5 /SYS/MB/NET2
>
> OK?
Anyone? I'll probably just commit in a few days unless someone objects,
printing device names is a nice aid in partitioning machines, especially
since picking the wrong iodevice needs power cycling and might even
prevent the primary domain from booting since another guest domain
accidentially got its root disk device.
PS: with the new mdprint port on ports@ one can easily inspect the PRI
and verify:
$ mdprint -pqng component.assignable-path,component.nac ./pri |
> grep assignable
component|assignable-path="/@400/@2/@0/@8"|nac="/SYS/MB/PCIE0"
component|assignable-path="/@500/@2/@0/@a"|nac="/SYS/MB/PCIE1"
component|assignable-path="/@400/@2/@0/@4"|nac="/SYS/MB/PCIE2"
component|assignable-path="/@500/@2/@0/@6"|nac="/SYS/MB/PCIE3"
component|assignable-path="/@400/@2/@0/@0"|nac="/SYS/MB/PCIE4"
component|assignable-path="/@500/@2/@0/@0"|nac="/SYS/MB/PCIE5"
component|assignable-path="/@400/@1/@0/@8"|nac="/SYS/MB/PCIE6"
component|assignable-path="/@500/@1/@0/@6"|nac="/SYS/MB/PCIE7"
component|assignable-path="/@400/@1/@0/@c"|nac="/SYS/MB/PCIE8"
component|assignable-path="/@500/@1/@0/@0"|nac="/SYS/MB/PCIE9"
component|assignable-path="/@400/@2/@0/@e"|nac="/SYS/MB/SASHBA"
component|assignable-path="/@400/@1/@0/@4"|nac="/SYS/MB/NET0"
component|assignable-path="/@500/@1/@0/@5"|nac="/SYS/MB/NET2"
That's how ldomctl works around iodevices: They're "component" nodes in
the tree that have an "assignable-path" attribute; ldomctl picks those,
assigns whatever is specified in ldom.conf to guest domains, and assigns
all remaining components to the primary domain.
Index: config.c
===================================================================
RCS file: /cvs/src/usr.sbin/ldomctl/config.c,v
retrieving revision 1.34
diff -u -p -r1.34 config.c
--- config.c 21 Feb 2020 19:39:28 -0000 1.34
+++ config.c 7 Mar 2020 16:39:25 -0000
@@ -48,6 +48,7 @@ TAILQ_HEAD(, core) cores;
struct component {
const char *path;
+ const char *nac;
int assigned;
struct md_node *hv_node;
@@ -216,6 +217,7 @@ pri_init_components(struct md *md)
struct component *component;
struct md_node *node;
const char *path;
+ const char *nac;
const char *type;
TAILQ_INIT(&components);
@@ -228,6 +230,10 @@ pri_init_components(struct md *md)
if (md_get_prop_str(md, node, "assignable-path", &path)) {
component = xzalloc(sizeof(*component));
component->path = path;
+ if (md_get_prop_str(md, node, "nac", &nac))
+ component->nac = nac;
+ else
+ component->nac = "-";
TAILQ_INSERT_TAIL(&components, component, link);
}
@@ -2889,7 +2896,8 @@ list_components(void)
pri_init(pri);
+ printf("PATH\t\tNAME\n");
TAILQ_FOREACH(component, &components, link) {
- printf("%s\n", component->path);
+ printf("%s\t%s\n", component->path, component->nac);
}
}
