[02:37:22] *** Quits: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97) (Quit: Page closed) [08:31:52] *** Joins: lhodev (~Adium@inet-hqmc02-o.oracle.com) [08:32:00] *** Parts: lhodev (~Adium@inet-hqmc02-o.oracle.com) () [10:38:59] jimharris: I feel much better knowing it does return all 0xF on a physical hotplug [10:39:06] that makes sense that the memory doesn't change on sysfs [10:45:33] *** Quits: sethhowe_ (sethhowe@nat/intel/x-jvyugvawtxkoywle) (Remote host closed the connection) [10:47:24] *** Joins: sethhowe (~sethhowe@192.55.54.42) [11:14:24] *** Quits: sethhowe (~sethhowe@192.55.54.42) (Remote host closed the connection) [11:16:15] *** Joins: sethhowe (~sethhowe@192.55.54.42) [11:53:34] bwalker: posted comments on the for_each_channel async patch: https://review.gerrithub.io/#/c/391309/ [12:28:06] drv: so i can no longer run astyle on my system - the version i have doesn't understand "add-braces" [12:28:51] i know astyle has always had some slight differences between versions [12:39:16] jimharris: I think that may be new with astyle 3.0 [12:40:20] what does astyle -V say on your system? [12:40:31] thinking maybe we have two different .astylerc files [12:51:08] $ astyle -V [12:51:09] Artistic Style Version 3.0 [12:51:38] $ astyle -V [12:51:42] Artistic Style Version 3.0.1 [12:51:44] I think mine is locally installed, not from the package manager [12:51:54] one upped! [12:51:57] since Fedora had a pretty old astyle version for a while [12:52:06] mine is from the package manager I think - let me check [12:52:31] yeah, mine is packaged on fedora 26 [12:52:32] 3.0.1 [12:52:33] yeah, looks like Fedora 26 has 3.0.1 [12:53:16] jimharris: what version do you have? is it from Ubuntu? [12:54:46] 2.06 [12:54:48] yes, Ubuntu [12:54:51] 17.04 [12:56:05] there's -j option that's the same for --add-brackets and --add-braces [12:56:43] --add-brackets was deprecated and got replaced in newer version with --add-braces [12:59:17] and looks like we can just put "j" in astylerc and it works (at least on 2.06) [12:59:27] hmm, if add-brackets works in old and new, that seems fine [12:59:32] gold star for darsto_ :) [12:59:54] or we just put "j" in astylerc with a nice comment, so when they yank --add-brackets later it doesn't break us again [13:00:40] drv: can you check both --add-brackets and j in astylerc on your system? [13:02:02] both seem to work OK for me [13:02:13] i'm fine with either [13:02:16] I'm fine with either one, since we already have a comment there [13:02:26] the astyle news page says "The old options and method names have been depreciated, but will continue to be accepted for the next several releases." [13:02:35] so it's probably best to pick j [13:03:27] depreciated - so they've gone down in value [13:04:05] :) [13:04:06] yes, after several releases their value will be zero [13:04:20] lol [13:04:38] ok, pushed https://review.gerrithub.io/391477 - please test with the older astyle [13:34:38] looking at spdk_blob_close and this spdk_blob ** argument [13:34:58] we have inconsistencies here currently - in some error cases we NULL the pointer and others we do not [13:35:57] *** Quits: drv (daniel@oak.drv.nu) (Ping timeout: 240 seconds) [13:39:17] i know the original idea was to use this as sort of a way to enforce the user doesn't use that spdk_blob pointer again after it's been closed, but I'm not sure we should do that for asynchronous routines which could fail [13:39:44] so it works great for spdk_poller_register, but is a bit of pain here [13:40:18] as part of these blobstore API changes, any objections to changing this to just a spdk_blob *? [13:41:45] spdk_blob_close is asynchronous now, right? [13:41:51] yes [13:42:02] then we can probably just make it spdk_blob * - that's fine with me [13:42:17] i know drv like the ** paradigm [13:42:27] likes [13:44:01] *** Joins: drv (daniel@oak.drv.nu) [13:44:01] *** ChanServ sets mode: +o drv [14:17:12] *** Joins: asdw (493d1235@gateway/web/freenode/ip.73.61.18.53) [14:17:20] bwalker: at some point didn't we have a check for crossing blob opens? [14:17:50] or did we just talk about adding that? [14:18:26] Quick question, is the Intel Optane 900P supported by SPDK? I'd assume NVMe is more or less well standardized? [14:23:03] jimharris: I can't remember - we should though [14:23:21] asdw: I don't have an Optane 900P to test with, but it should just work. I do have a P4800X that is working [14:24:37] most devices just work because NVMe is reasonably well defined [14:24:51] but there are a couple of quirks for some devices that we work around - see the top of this file: https://github.com/spdk/spdk/blob/master/lib/nvme/nvme_internal.h [14:26:01] if it doesn't work we'd love to hear about it so we can fix it [14:36:50] *** Quits: asdw (493d1235@gateway/web/freenode/ip.73.61.18.53) (Ping timeout: 260 seconds) [16:06:23] *** Joins: Shuhei (caf6fc61@gateway/web/freenode/ip.202.246.252.97)