i've not run them yet... not sure if my HW even has any devices that could be used

there are test devices, you dont need hardware

I've not seen it fail, sorry.

They're part of the standard os-tests.

[illumos-gate] 18115 Update Intel microcode to 20260512 -- Dan McDonald <danmcd⊙ei>

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?

Even if it's just "rewrite the patch/add more detail", I'd be happy for any feedback

have you had anyone review your change?

not yet, wasn't sure who to poke

it's fairly common to ask for reviews on the illumos-developer mailing list

though not required

(the requirement is just that the code needs someone else to review and approve it)

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!

there's a link somewhere I don't have offhand

but basically once reviewed, you'll also want to update the issue w/ the testing done

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)

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

sounds good, I saw all the RTI stuff in the docs but looks like getting to that point is a bit more informal

we try to shrink to fit based on the size/risk of the change

it'd be nice if dtrace could map ioctl values to symbolic names like truss does...

now I think I understand why STREAMS is yelled

i'm at a loss why udp<->timod would be the 'stack' on /dev/console... that feels very wrong

jbk: doesn't truss just have a huge table it "knows" per device?

the whole way in which we do ioctl is a bit sad :|

we predate the macros, basically

yeah

(it's several tables)

with some conflicts with some historical ioctls;)

jbk: in a similar spirit, I sure wish people didn't ... arbitrarily not use enums? somehow?

so many `#define THIS_IS_A_MISTAKE 3` that the debugger could know the name of

I'm not quite at the point of `const int THIS_IS_A_MISTAKE = 3` but definitely enums of groups of them

yeah, i try to do that when I can, though doesn't do much for existing code...

this is just such a bizarre one...

on a physical machine, a process opening /dev/console, and writes \e[18 (report terminal size)

and the resulting queue in struct tem_vt_state seems corrupt or wrong

the q_stream is pointing back to a stream where udp + timod are pushed on it

but same process on a VM, it looks a lot more normal

I'm trying to avoid an unfortunate mdb interaction. Do we have anything in the base system that will buffer stdin to stdout?

think mbuffer

`dd bs=$((1024*1024)) conv=block 2>/dev/null` # the old ways are coming back to me