I've yet to meet an IB+RDMA fabric that worked for months at a time

And RoCE just makes it worse

anyone want to revieuw code.illumos.org/c/illumos-gate/+/2665 ? Send a mail to the list a while ago but looks like there waa bo response

→ CODE REVIEW 2665: 15271 document viona tunable to force copy of tx buffers (NEW) | illumos.org/issues/15271

@mxshift we are going to attempt to use DRBD with RDMA with roce lol

may the force be with us :)

illumos.org/issues/15435 looks like a loose end in libtopo

→ BUG 15435: libtopo fails to build when fprintf is marked __PRINTFLIKE() (New)

[illumos-gate] 3816 "zfs allow" mis-displays filesystems with "allow -c" but not "allow -s" set -- Bill Sommerfeld <sommerfeld⊙ame>

illumos.org/issues/15434 is another long-lurking bug in apparently dead code.

→ BUG 15434: libima fails to build when sprintf is marked __PRINTFLIKE() (New)

Burn it all, sommerfeld! :)

I hope some folks who actually understand that libtopo thing take a look.

jclulow, rmustacc: I think you're best placed to understand/know someone who understands, libtopo

that was part of the work rob was doing to encode storage topologies (e.g. SAS, FC, ..) into fma

i suspect it was more for completeness w/ processing an nvlist vs. being explicitly relied upon

yeah, though it wasn't actually complete. IMHO would be better to just limit to the kernel nvlist dialect (no doubles)

there's some standard storage library (like libHBAAPI.so or something like that) what I think comes into play.. I don't think there's anything there that'd be represented as a double (as that could be another potential source besides the kernel)

i'd like to pick that up and try to finish it at some point since it'd be really nice for fma to understand topologies for fault analysis

but too many other things keep getting in the way

like i40e :)

there's not a lot of DATA_TYPE_DOUBLE references in illumos-gate

I roughly understand libtopo, add me to something if you need a review sommerfeld?

.. or nvlist_add_double()

I have had to limit certain kernel things to avoid double on arm

for reasons

and perhaps temporarily

will do.

but less double's in the kernel would certainly make me happy

this is one point in userspace which is converting nvlist to xml and back again

I was just commenting on "limit the kernel dialect", I think I had to do that for kstats and and nvlists (both shoddily, right now).

if the nvlist has a double in it, current code will match up the double with a %s format, interpret the double as a pointer and likely fall over.

with gcc on arm, if you don't use the FPU you literally cannot spell 'double'

(there's nothing to store them other than in the FP registers)

(because of a missing comma resulting in string literal concatenation. comedy of errors..)

oof

if the comma is inserted it still emits xml calling a float a uint64 so it's not going to round-trip back to nvlist as a double.

(all of the above assuming I'm reading the code correctly)

I was staring on that line trying to see the difference, took some time till I found the missing comma:D

sommerfeld: Sounds like I should take a look at the write up on 15435 when I get some time?

there's not much to it.

If this is in the digraph stuff, I have to build more of those soon.

But just wanted to answer Rich's ping but can't really look right now.

rmustacc: though one of the things that concerns me is that it looks like most of the places that call nvlist_add_double() are in usr/src/lib/fm/topo ...

yeah, I wasn't so much trying to ping you both (sorry), but tell sommerfeld who might be around with the expertise

if not you two, then someone you hired I forgot about.

but presumably those nvlists don't get fed through the xml converter or else this would have been noticed

I'm not anywhere close to starting to push changes for review; I'm just filing bugs when I notice anomalies like this.

setting up so that when I do start sending stuff for review the weird special cases are isolated from the boring stuff that just does %d -> %zd or similar things.