dtrace: failed to compile script unixso.d: line 1: useless declaration

any idea how can I find the useless declaration?

I'd start by looking at the first line of unixso.d

Error comes frmo here: code.illumos.org/c/illumos-gate/+/3208

→ CODE REVIEW 3208: 16149 intrd leaks memory (NEW) | illumos.org/issues/16149

oh, oops, not there.

try here:

sommerfeld I'm stuck at a simpler place now

basically

sockaddrv = (struct sockaddr_un *)arg2;

trace(sockaddrv->sun_path);

I cannot get the path. I know I have to use copyinstr

but I'm having a hard time understanding where

what are you tracing?

userland program? or a kernel function?

-18C. nice.

jbk a userland application

then maybe trace(copyinstr(sockaddrv->sun_path))

tsoome: sounds like a midwest winter :)

n/win 23

if you were wanting driver code to read to complement reading the STEAMS Programming guide, is there a driver that's conceptually simple I should start with?

I know I'm totally out of my depth trying to understand how to contribute ath, or port a more recent wifi driver. If there's the equivalent of a wading pool, I should probably start there.

If you're wanting wifi drivers, think about STREAMS as little as you can, look into the gldv3 drivers

I haven't looked at the Sun version, but I wrote a version of atu(4D) for myself years ago, and that's a super simple device to learn how to get yourself into the network stack etc.

are the virtio drivers worth learning? I was imagining they might be interestingly trivial.

they could be, I didn't think of that, but I haven't looked at them really either.

so just all of uts/common/io/mac, right?

oh, _provider first I see

they're i think simpler than many drivers since they don't have to worry as much about hw variants, other bits that might be relevant for physical hardware, etc

but not sure if that means they're 'simple'

yeah, that was my logic with atu too, it's a very pair of usb pipes, as best as I remember

the extent of my experience writing STREAMS drivers is writing a keyboard driver for hyper-v

which wasn't tooo bad

more of the issues weren't really STREAMS related

but more all the undocumented assumptions about what things you have to implement

as well as how we deal with keyboards as the console input device

where we (almost certainly for legacy, and probably even pre-ACPI legacy reasons) bake in certain assumptions

it wouldn't surprise me if we could simplify a lot of that

anything I should keep my eyes open for? I'm likely to assume complexity is necessary until I have a lot more reading under my belt.

[illumos-gate] 16146 webrev.sh and flg.flp.sh need some style updates -- Bill Sommerfeld <sommerfeld⊙ho>