tsoome: did your mdb_printf fixes come with a PRINTFLIKE annotation somewhere?

yes

but apparently the mdb print support is not trivial and needs more than just filling up few tables, I havent had time to dig deep into it, but then again, even simple approach is rather revealing....

it's missing more formatting?

mixed up, usual stuff - signed versus unsigned, long versus not long or long long etc.

like this one too: ../../../common/modules/genunix/avl.c:107:63: error: format '%d' expects argument of type 'int', but argument 3 has type 'size_t' {aka 'long unsigned int'} [-Werror=format=]

ahh.. so more callers are the issue

yep.

the same old story, compiler can help us, but the feature is either not implemented or warnings are disabled...

yeah.. i try to remember when messing with a module to try to clean up any silenced warnings while I'm in there unless it's too messy and really needs a dedicated change

printflike isn't silenced in the traditional sense

the problem is that we use `-fno-builtin` which means the compiler (rightfully, but annoyingly) can't assume what `printf` etc are

so we lack it in places we didn't annotate (annoying), and in places we shouldn't have to annotate

but we sort of asked for it to be a pain

no, with printf the problem is that we need compiler support (like there is for cmn_err()), and it is something we havent implemented yet. thats it.

tsoome: actual printf(3c)? no that's not it

mdb_printf() yes, that's what I was asking for :)

(because otherwise it won't know %H, the best format character ever)

with printf(3c) we have unrecognized "%ws", and some other minor details.

and yes, mdb printf is much more "fun".

but %ws prevents us to annotate printf family for userland. at least as much as I have played with it.

ofc the good question is, should we actually have that %ws.

tsoome: probably if you follow that thought too far the answer is related to the standards check symbols we have

so that we support %ws _unless_ ...

(and anything else that isn't in the standard, when the runtime standard bits are set)

and the compiler would agree with that via -std=...

and

so a very early drafty take on the TCP small queues thing I was talking about yesterday: code.illumos.org/c/illumos-gate/+/4594

→ CODE REVIEW 4594: 17909 tcp could benefit from a small-queues transmit throttle (NEW) | illumos.org/issues/17909

sommerfeld: i see you and danmcd have similar taste in magic constants :)

Yeah, it's my fault. Plus 0x90125xxx needs an xxx I can't think would have a good answer off the top of my head.

(*partially* my fault to be 100% accurate... I can't speak for sommerfeld)

jbk: indeed

am I missing a reference or cute trick in the numbers?

There are a pair of initializers in his changeset. And the hint is "album names".

Also cf. ipseckey(8). Also, for even more blatant ones, cf. ike.preshared(5)

oh, rush

and probably van halen

^^^ give that man a prize!

sorry, I'm old but younger, and I always assume there's math I don't know :)

was hoping for comments on the content rather than the magic numbers but I'll take what I can get...

No sorry needed!

(and those magic numbers will go away when I fix up how the buffer is allocated..)

sommerfeld: Not enough review brainpower for that today. All of that is $DAYJOB related for the next several days.

sommerfeld: unfortunately, the meat of my look at it was judging how much I would need to do in remedial study to have opinions

so I think having attracted rpz to it is the best I can probably achieve

The fact that driver reclaim tweaks are required has me concerned about the solution space and what assumptions this is going to create and assume.

It's not clera from reading the ticket why the proposed solution is the right one and how we expect it to change and impact things. Particulalry when the way traffic to zones works means you have no assumptions about quick freeing of data.

I think there's enough there to buy the problem.

And to be clear, it all might be, but just saying for the few paragraphs for a fundamental design change and the throwaway driver problem leaves me with more questions than answers.

mblk_t lifetime isn't tied inherently to the protocol lifetime, paticularly when going across mac loopback.

yeah, much to think about here but unfortunately I have to run right now...

[illumos-gate] 17900 svc/configd: format issue while printing pid_t -- Toomas Soome <tsoome⊙mc>