00:37:11 i've not run them yet... not sure if my HW even has any devices that could be used 00:39:16 there are test devices, you dont need hardware 00:40:35 I've not seen it fail, sorry. 00:40:49 They're part of the standard os-tests. 01:52:19 [illumos-gate] 18115 Update Intel microcode to 20260512 -- Dan McDonald 02:44:34 Hey! New contributor, I recently opened a new bug report 18109 and created a short CR that should resolve the issue. Wondering if there's anything else I should do to help push things along? 02:45:09 Even if it's just "rewrite the patch/add more detail", I'd be happy for any feedback 02:48:14 have you had anyone review your change? 02:51:41 not yet, wasn't sure who to poke 02:52:09 it's fairly common to ask for reviews on the illumos-developer mailing list 02:52:36 though not required 02:55:01 (the requirement is just that the code needs someone else to review and approve it) 02:58:24 Gotcha, I'll send something in there. I was looking at some other issues/CRs but it looks like things are a bit spread out over irc, etc. I appreciate it! 02:58:50 there's a link somewhere I don't have offhand 02:59:14 but basically once reviewed, you'll also want to update the issue w/ the testing done 03:00:29 and then submit a request for integration to the illumos-advocates list and include a link to the gerrit review, a copy of the mail_msg from the build (should include a debug and non-debug build -- this is usually done in your illumos.sh file) and a link to the ticket (just makes it easier to check everything) 03:01:24 if it's all good, it'll get merged (depending on how busy everyone is, may be a few days), or if there's questions, they'll let you know and you can address as needed 03:01:25 sounds good, I saw all the RTI stuff in the docs but looks like getting to that point is a bit more informal 03:02:23 we try to shrink to fit based on the size/risk of the change 17:31:42 it'd be nice if dtrace could map ioctl values to symbolic names like truss does... 18:20:26 now I think I understand why STREAMS is yelled 18:38:56 i'm at a loss why udp<->timod would be the 'stack' on /dev/console... that feels very wrong 19:37:08 jbk: doesn't truss just have a huge table it "knows" per device? 19:37:20 the whole way in which we do ioctl is a bit sad :| 19:37:25 we predate the macros, basically 19:41:19 yeah 19:47:49 (it's several tables) 20:44:35 with some conflicts with some historical ioctls;) 21:07:40 jbk: in a similar spirit, I sure wish people didn't ... arbitrarily not use enums? somehow? 21:08:04 so many `#define THIS_IS_A_MISTAKE 3` that the debugger could know the name of 21:08:37 I'm not quite at the point of `const int THIS_IS_A_MISTAKE = 3` but definitely enums of groups of them 21:12:33 yeah, i try to do that when I can, though doesn't do much for existing code... 21:13:35 this is just such a bizarre one... 21:18:42 on a physical machine, a process opening /dev/console, and writes \e[18 (report terminal size) 21:18:57 and the resulting queue in struct tem_vt_state seems corrupt or wrong 21:20:10 the q_stream is pointing back to a stream where udp + timod are pushed on it 21:20:26 but same process on a VM, it looks a lot more normal 21:28:35 I'm trying to avoid an unfortunate mdb interaction. Do we have anything in the base system that will buffer stdin to stdout? 21:28:43 think mbuffer 21:32:41 `dd bs=$((1024*1024)) conv=block 2>/dev/null` # the old ways are coming back to me