10:10:41 <Agnar> according to the illumos HCL, the LPe11000 and LPe12000 cards should work, but according to the driver it's unsupported?! Apr  4 22:27:41 gem emlxs: [ID 349649 kern.info] [ B.1C2C]emlxs1:  ERROR: 101: Driver attach failed. (Unsupported adapter found. Id:35  Vendor id:0x10df  Device id:0xfc40  SSDID:0xfc41  Model:LPe12000-S)
10:34:20 <tsoome>  /* Oracle branded adapters are not supported in this driver */
10:34:44 <Agnar> oh, there was something
10:35:34 <Agnar> thanks for bringing that back up. would it help to flash a different firmware on it? I guess no?
10:35:44 <tsoome> you can try, I guess
10:36:51 <Agnar> I'll check if broadcom still has firmware for those cards...
10:37:23 <tsoome> I'd check with Carsten - maybe he can comment about background there
10:37:54 <Agnar> good idea
11:04:31 <gitomat> [illumos-gate] 16423 Import fletcher-4 algorithms from OpenZFS -- Andy Fiddaman <illumos⊙fn>
18:46:13 <gitomat> [illumos-gate] 11745 fmdump missing -i and -I parameter documentation in the man pages -- Keith M Wesolowski <wesolows⊙oc>
19:37:15 <richlowe> so after a bit of a journey, I've re-discovered that a set of our false positive smatch warnings are because of old-style flexible array member declarations.  `struct foo { char foo[1]; }`. That, for instance, is why smatch things zfs_ctldir.c overflows strcpy()
19:37:31 <richlowe> seemingly smatch knows(?) that [0] is special, but takes [1] to mean [1]
19:37:51 <richlowe> what I don't know, is what the implications are of making them new-style 
19:38:10 <richlowe> beyond -- I assume -- all the structs being a perhaps very shitty to discover byte shorter.
19:38:49 <rmustacc> So, the old style unfortunately trips over the modern optimizer.
19:38:59 <rmustacc> [0] is a GNU extension, so it knows that it's like C99 [].
19:39:19 <richlowe> ok, sorry, I thought [0] was the c99
19:39:21 <rmustacc> The main implications are either GNU 89 or C 99, and the size implications.
19:39:54 <rmustacc> So in non-public structures, I could go to C99 [] if you can.
19:40:18 <richlowe> and then audit for allocations that assume a -1
19:40:25 <rmustacc> Yeah.
19:41:02 <rmustacc> I dealt with some C99_FEATURES related bits for this for new public versions of this in the xregs procfs.
19:49:09 <sommerfeld> I suspect the rationale for what smatch does is that [0] could only possibly be useful for a flexible array, but [1] could really mean [1]..
19:54:34 <richlowe> Yeah, the rationale is fine, it's the fixing it.
19:55:42 <sommerfeld> the one to watch out for when auditing is where the extra byte is used for a null terminator.  Or when it's using sizeof(struct foo) and it's actually a delta of alignof(something) rather than 1.
19:56:16 <sommerfeld> (sizeof(struct foo) rather than sizeof(foo.foo) that is)
21:36:18 <tsoome> comstar also has very annoying take on structures...