12:16:29 Do we have replacement for http://www.opensolaris.org/os/community/dtrace/dtest? see usr/src/cmd/dtrace/test/README (or /opt/SUNWdtrt/README) 14:27:39 tsoome_: I'm going to look at archive.org's view of it from back in the day. It might've moved to somewhere on dtrace.org. 14:29:47 cool:) 14:30:40 ah, lost my tail finally. 14:30:44 Well, here's the archive.org URL for it... 14:30:45 https://web.archive.org/web/20100828154214/http://hub.opensolaris.org/bin/view/Community+Group+dtrace/dtest 14:30:53 Can't find it on dtrace.org easily. 14:32:37 And it's clearly old (last days of OSol). Someone with more intimate knowledge of DTrace can clarify. 14:33:06 The most knowledgable people on that topic, however, have much different things in their L1 caches right now. 14:34:23 apparently needs a bit adjusting, and definitely we should host it somewhere:) 14:35:05 my first reaction was just from seeing that obviously non-working url. 14:38:02 archive.org is very useful for old URLs. 14:39:17 indeed. but we should provide a bit more recent information still:) 14:41:10 also, apparently dtrace does not grok flexible array members. so it does not work on those headers we now have... 14:41:42 /usr/include/sys/dld.h failed: dtrace: failed to compile script /dev/stdin: [D_DECL_VOIDOBJ] "/usr/include/sys/mac.h", line 116: cannot have void member: mpur_data 15:41:36 that reminds me... i need to update libctf to handle anonymous unions member lookup for c11 16:40:27 tsoome: Did my cleanup effort cause a problem for dtrace? https://github.com/openzfs/zfs/commit/8e7ebf4e2d1a7a3d175de54c74869c0d19f290e6 https://github.com/openzfs/zfs/commit/9c8fabffa2b15a4ada570c8c469ff0709d00b003 16:42:05 Flexible array members were supposed to remove a GNUism from the code, make size calculations easier to maintain and be compatible with fortify source and ubsan. :/ 16:42:57 ryao yes/no, the problem is that dtrace does not seem to support this construct, and we have some structs defined using this mechanism. 16:45:19 tsoome: If you can modify dtrace to treat it like [0], that might make dtrace happy. Compilers supposedly treat them differently, but the semantics on paper really should be identical. 16:45:29 Although that is a GNUism. 16:45:46 So, you can not use system header with this struct, but need to construct something... 16:46:33 It sounds like a parsing issue. I wonder if dtrace is okay with the [0] GNU hack. If it is, then just changing the parser to treat it the same way might work. 16:47:59 There are three variations of the same idea in the C world. VLAs were the standard's approach for dealing with it. The GNU approach were zero-length-arrays with [0]. The original ANSI C approach was to use a single member array and just do the right thing with allocations/frees and pointer manipulations. 16:48:12 yep, parsing for sure, maybe something more too, because the feature is there to create access to larger chunk of memory:) 16:49:03 Having recently touched this in OpenZFS, it is rather fresh in my mind. The semantics of the GNU hack and the VLA are so similar that you can literally just change the headers to go from one to another and everything should just work. 16:49:27 yep 16:49:28 Hence why I think getting the parser to treat it like the GNU hack would work if DTrace supports the GNU hack. 16:49:59 of course, the gnu vla has problem with static analyzers:D 16:51:10 Well, we are talking about the DTrace parser here. If it is able to handle the GNU zero-length-array in a sane way, then treating VLAs as the same thing should be fine. What static analyzers think about the GNU zero-length-array does not matter in the context of dtrace mapping VLAs to the GNU hack. 16:51:47 yes. 16:51:58 Also, I don't quite understand why static analyzers have a problem with the GNU hack given how similar the semantics are. Maybe it has something to do with the compiler not complaining if you do something silly like put a zero length array in the center of another structure. -_- 16:54:30 even gnu c itself is complaining:D 16:55:15 probably want people to switch to flexible arrray. 17:03:28 @pmooney --> added another commit to the illumos-joyent 14892 branch that you'll probably want. There's mention of "common.h", but no "common.h" for signalfd tests. Fixed that. Also plumbed in building from nightly and IPS manifest entries 17:04:15 yeah, I skipped the makefile/manifest stuff on those since they weren't done 17:04:52 hence the commit titles with the XXX prefix 18:00:34 [illumos-gate] 15287 dtrace: remove pragma ident -- Toomas Soome 18:03:31 whee. now 2 last ones left. unfortunately, those are the largest 18:35:07 Asked to make sure that I didn't miss anything, thanks pmooney 19:01:54 do any of you have LD_AUDIT libraries you're particularly aware of? 20:32:45 i've never seen them used myself 20:37:33 adam added one for dtrace magic 20:37:36 but it doesn't do what I need 22:08:38 [illumos-gate] 15327 add misc datalink class -- Luqman Aden 22:52:54 my hat of to the MATE gui designer that did the keyboard layout dialog 22:53:30 too big to fit in a VirtualBox screen before installing guest additions 22:54:31 I don't think they are aware of 40% keyboards then 22:54:36 and the stupid big keyboard picture acts as a trap for the tab key and you cant tab past it to get to the OK button that you can't see 22:54:54 total epic GUI fail 22:55:16 Live CD? 22:56:39 just installed and trying to configure 23:00:57 and it is dog slow on my old Solaris 11.3 host 23:11:16 still its much much slower than kubuntu and opensuse over 10 minutes to boot 23:11:50 Only first time, while it's finishing the service database import 23:12:06 no it's done that 23:12:22 i managed to install vbox gues and rebooted 23:12:27 10 minutes seems way to long 23:12:44 mines usually go up in seconds 23:12:55 come up 23:15:07 its just dog slow barely any disk activity 23:21:37 Ooh nwam timed out message 23:22:12 probably gave up waiting 23:22:25 ah, yeah you might want to switch to network/physical instead and ipadm create addr -T dhcp on the interface 23:24:52 Oh no 23:25:12 it's updated the boot cache and is rebooting 23:25:21 it's already tomorrow 23:26:51 they're both network/physical, it's network/physical:default v. network/physical:nwam 23:27:47 need to sleep can't wait another half hour for it to start 23:28:27 maybe an entire weekend will be enough