13:51:57 <kebe> Can someone on OI or even Helios please utter:   `echo "::print -ath vnode_t" | mdb -k`  and mail me or pastebin the results?
13:52:50 <andyf_> kebe https://paste.ec/paste/-Oqhouv1#r6VA2zaE5i8Xav7v+2ss-ceSSfSMCgM23FTKHl/U2Vd
13:54:55 <kebe> Thank you.  Moving it to the end or shoving it between v_type and v_rdev would solve the problem poor Laquen discovered the hard way...  (look at those holes!)
14:01:17 <kebe> But (as I said on twitter to jbk) if we make the change there's this whole range of {Omni,Smart}OS with vnode_t that's "off".
14:02:47 <toasterson> Well, one of the two versions will need to recompile to reconcile.
14:04:23 <toasterson> Thing is both {Omni,Smart}OS have releases so it will be quite near impossible to have one version for both releases
14:10:58 <kebe> I'm in the midst of filing an OS-bug (whether it gets fixed or not is a different question) to address this.
14:11:57 <kebe> WIth SmartOS the usual answer is "just upgrade to $LATEST" and that's it.  It's harder with Omni and its Stable or LTS (and I won't claim to speak for Omni's opinion on all of this).
14:38:39 <pmooney> kebe: was there ever a contract for the contents of vnode_t?
14:39:28 <kebe> AFAICT, no.  But I did have flashbacks to the 90s where I was admonished for altering ill_t similarly because 3rd party FW vendors (e.g. Checkpoint) requred ill_t offsets to not change if possible.
14:39:48 <kebe> I'm writing up the tradeoffs in an OS bug that I will make public immediately after filing.
14:41:11 <kebe> https://smartos.org/bugview/OS-8419
17:33:10 <jclulow> pmooney: There is a pretty explicit comment about a set of public members, I think, in the vnode_t
17:33:37 <jclulow> It would be better of course to provide accessor symbols for the things people actually need to do
17:33:52 <jclulow> and, really, any documentation haha
17:34:03 <pmooney> yeah
17:34:21 <jclulow> My kettle is already boiling a different part of the ocean though
23:15:37 <richlowe> has anyone seen blkdev unbinding a bad dma handle under vioblk?
23:15:40 <richlowe> (or even not under vioblk)
23:15:46 <richlowe> bad in this case is baddcafe
23:44:22 <jbk> no.. closest was a fix from april by woodstock for the blkdev softstate, but no DMA handles
23:44:31 <jbk> (14654)
23:48:27 <richlowe> I just filed #15123 (fenix?)
23:48:28 <fenix> BUG 15123: blkdev can unbind an unbound DMA handle (New)
23:48:29 <fenix> ↳ https://www.illumos.org/issues/15123
23:48:42 <richlowe> I confess I don't understand why it's special casing a 0 transfer if it's not going to special case it fully
23:50:29 <richlowe> more importantly, I can't test my hypothesized fix in any kind of real environment in the same way you, Hans, etc could.
23:50:46 <richlowe> but I feel like the fix is more a bandaid for whatever half-complete special casing is trying to happen there
23:52:42 <jbk> yeah, not sure what the thought process there was