I guess one question is what the memory map looks like on each node and how you "name" the chunks of memory across the set of cooperating processors.

So, first I don't think CPUs can reach remote memory.

Certainly, the other stuff suggests that a single system is the coherency domain and that the local CPU can cache the local GPU's memory coherently, but I don't see anything beyond that.

It's also not clear to me that the remote GPU stuff is coherent per se, so I think if you were looking for a place to research, I'd go to how does this work with CUDA across multiple GPUs connected via NVLink today.

👍

I've seen some indications that perfect coherency was surprisingly unimportant for ML training job communications(!)

Coherency is expensive.

[illumos-gate] 15496 dr: array subscript 3 is above array bounds -- Toomas Soome <tsoome⊙mc>

when upgrading, how does smf determine if it should (re)import a manifest? I thought I found the bits that do that a while ago, but can't find it now, and I can't recall if it's just looking at a timestamp or doing a checksum of some sort on the manifest itself...

jbk: I also vaguely recall finding that recently and don't remember the answer..

comments in /usr/src/cmd/svc/manifest-import strongly imply a hash

yeah, i encountered it somewhere in the past, but can't remember where now, or find it again :)

svccfg -s smf/manifest listprop dumps all the hashes. there's a pair of framework properties for each imported manifest with the pathname and a hash value

usr/src/cmd/svc/common/manifest_hash.c

using (alas) MD5

not because it's a vulnerability, but because it creates the possibility that you might need to prove to people that it's not a vulnerability in this application...

block comments around mhash_test_file() explain what it's looking for...

two hashes - one of file metadata, one of file contents.

@sommerfeld MD5 as CRC or as something actually secure?

I think the hash is used for rename detection or something? but it's been ages

and liane only explained the rename stuff to be very briefly, and in terms centered on it being a shame

but I thought it was in the same tub of magic as the `cmd/svc/shell/mfsthistory` file

but I could be 100% wrong

danmcd: used as change detection.

like I said, "use of MD5 creates creates the possibility that you might need to prove to people that it's not a vulnerability in this application.."

used only on files contained in directory hierarchies that ought to be writable only to system administrators.

sommerfeld: agreed

given an fd that's an open device node (i.e. S_ISCHR(mode) != 0), what would be the easiest way to determine the name of the driver for that (userland)?

get major number of st_rdev, convert to decimal, grep in /etc/name_to_major ?

(spot checking this appears to produce sane results)

(if you need to do this a lot, build an index, but you said "easy"..)

I had thought there was something in libdevinfo, but I'm not finding it

(probably to go from a major to a node to a name, but...)

jbk: github.com/illumos/illumos-gate/blo…rc/lib/libdevinfo/devfsinfo.c#L1502

(modctl is private, but that is the meat you would grind your interface from)

It's been long enough where I don't remember --> How do you determine which versions of `gmp`, `mpc`, and `mpfr` to use with a given version of gcc? Asking for a gcc14-curious friend. :)

[illumos-gate] 16867 gcc 14 needs to use -gstrict-dwarf afterall -- Toomas Soome <tsoome⊙mc>

I just use the latest, I don't remember having to use specific versions

Gotcha. Latest it is.

is it possible to pass a virtual serial port using passthrough to bhyve ?, but what happens when that virtual serial port disappears?