hmm, I don't see any such warning in our current str*.3c man pages (which I split up into more reasonable chunks to great acclaim last year)

ah, I see the final note on your illumos.org/man/3C/string

yeah

which mostly survives in our docs.oracle.com/cd/E88353_01/html/E37843/strtok-3c.html except we dropped the reference to the compiler option since it's now default in all three compilers we care about

you can also see our docs.oracle.com/cd/E88353_01/html/E37843/string-3c.html is so much shorter now 8-)

See also: illumos.org/opensolaris/bugdb/bug.html#!7017461

→ OpenSolaris issue 7017461: string(3C) man page examples core dump when compiler defaults to xstrconst (Accepted)

I can't find a bug corresponding to why it was added, but I'd guess it was what you guessed or at least one pushy customer demanding we either "fix" it or document it

you also still have the "modern computer systems" usage note in illumos.org/man/3C/index which was originally a warning against assuming all the world was a VAX:

On the Sun processor (and on some other machines), you can \fINOT\fP use

a zero pointer to indicate a null string. A zero pointer is an error and

results in an abort of the program. If you wish to indicate a null

string, you must have a pointer that points to an explicit null string.

On PDP-11's and VAX'en, a source pointer of zero (0) can generally be

used to indicate a null string.

Programmers using NULL to represent an empty string should be

aware of this portability issue.

(from the SunOS 3.0 man page, the earliest I have)

amazing.

and of course we still have 0@0 just in case you want to _pretend_

(and haven't set the secflag that stops it working)

the file(1) implementation decides which character is used for ASM comments based on whether we're a pdp11 or not.

arguably wrongly

ran into that fixing that it decides whether a dump is "intel" or "sparc" based on which order the magic number is in.

(I guess nobody crashed enough on ppc to care)

on bsd 4.2/bsd 4.3 on vax, a.out format executables mapped their text starting at address 0, so null pointers could be dereferenced for read (but not write) by default.

rmustacc: are there any example of using the nic topo module in a topo map? I've not found any, but not 100% sure what i'd be looking for either

jbk: I've never used it in a topo map before. It normally has been enumerated automatically from the PCIe module.

*pci

Do you have something that's not driven by pci in this case?

well what I was hoping to do is right now the parent device for the port (i.e. the nic) gets a label of 'MB' which isn't particularly helpful when there's 4 MB NICs... i was hoping to be able to override it with the actual label in the back (based on the device path)

but maybe that's not possible right now?

smbios knows about the port, but I don't think the smbios info provides any way to link the two

jbk: Which smbios entry is it in?

SMB_TYPE_PORT

Yeah, there's not much we can do automatically there.

If only it was more like the on-board devices or others that also gave you a b/d/f.

there is an SMB_TYPE_OBDEVEXT as well w/ b/d/f but that doesn't give you anything to link to the port

it's just 'Intel X557-AT3 Ethernet #1' etc

Yeah, I get it. Just was wishing they had better ways of linking these things together, but they don't.

yeah, why i was hoping there was a way to do it with a topo map

So you could create a static node in it I think that has the label?

since the device path shouldn't change

That's nuanced.

That depends on the platform firmware not changing the b/d/f of everything along the way ever.

hrm.. it does seem though that the Reference Designator from smbios for the OBDEVEXT entries matches the device labeling method of the equivalent ACPI node, though I have no idea if there's anything wired up to utilize any of that (or if so, how)

the latter would allow mapping the driver instance (e.g. ixgbe0) to the ACPI device label

(which could be used to match the actual port name on the back)

Good evening all.

danmcd CET :-)

So just saying hi? Or do you have a question?

hrm..

is dtrace.org's ssl cert showing expired for anyone else?

I presume they were answering your question.

about timezone location.

(He said good evening so I figured it could be either hi or a prelude, nomad.) Self-signed certs says dtrace.org

jbk: I noticed that too

danmcd: yeah, but the expiration date

did you try to get to the dtrace book

yeah

illumos.org/books

was wanting to look up/confirm something

that has the actual book

Not After Tue, 22 Nov 2022 17:20:50 GMT

it's been over a month since the latest pkgsrc update. should we worry? :))

I don't think so tux0r.

danmcd Making more of an effort to engage with, and hopefully in, the illumos community :-). But I do have something approaching a question, regarding the cross-pollination of illumos on FreeBSD, should there be any interest in that topic?

grr.. this is annoying.. need to set a probe on a function in a shared library linked into a program

Wouldn't hurt to bring it up; we are aware of it, of course.

but dtrace keeps saying the probe doesn't exist

Try a -Z there jbk.

Can you specify library`name like you can in mdb's delayed breakpoints?

Yes, the shared object is the second part of the 4 tuple for pid.

(Technically the module part)

what is the actual value for the library used? e.g. it's get_id in libsec -- is that 'pid$target:libsec.so:get_id:{entry,return}'

or libsec.so.1

it's the SONAME I believe

either that, or the basename.

It's been a while since I traced something where they differed

I always did the full name.

But I don't know what's required. trace(probefunc) also helps.

(probemod)

But depending on lazy loading / dlopen deps sometimes it won't be there.

Sorry, probemod, yes.

[illumos-gate] 15603 SMB3 encryption interface updates for "large MTU" -- Gordon Ross <gordon.ross⊙tc>

ahh -Z seems to have worked... never knew about that one

-Z says ignore things that aren't here right at this moment.

It'll get revaluated when certain activity happens.

For example, the kernel will revaluate fbt probes on module load.

and rtld callbacks when things happen, yeah.

Yeah. It may not happen on dlopen.

thankfully it's linked and not dlopen()ed

The only real downside to -Z is you can't use args[].

speaking of that.. i should fix that for large chunk of kernel SDT probes where it's broken

It seems like FreeBSD has benefitted a lot from a good number of originally illumos features (Dtrace, ZFS and Boot Environments come to mind) and illumos (depending on the distro?) has benefitted in turn from originally FreeBSD features (Bhyve and the FreeBSD bootloader come to mind). I'm new to illumos but I'm learning as quickly as time allows.

While I'm much more familiar with FreeBSD than illumos it's easy for me to see that illumos still has a lot of very unique features. I was wondering what people here think about this cross-pollination between illumos and FreeBSD and what keeps you interested in using and contributing to illumos (or your illumos distro of choice)?

danmcd ^^^ A large question but hopefully an interesting one.

In general, where we can work together and mutually benefit, usually helps. That's true whther it's FreeBSD or other folks.

one thing i'd like to explore more (it'd likely end up as an IPD) though not sure there'd be much in the way of code sharing is freebsd's iflib handling of tx packets is pretty nice

If that's something you'd want to explore, I'd prototype something first.

it'd be opt-in, but for many ring-based NICs (i.e. i don't think mlxcx would benefit, but a lot of others could)

basically you give it the segmentation constraints and it presents you an array of the equivalent of ddi_dma_cookie_ts

taking care of any necessary segmentation, etc.

(and some bookkeeping about avail descriptors, etc)

I'd consider prototyping and blast radius. There are tradeoffs in a lot of directions.

[illumos-gate] 15824 want cxgbe FEC kstats -- Robert Mustacchi <rm⊙fo>

Anyone got any opinions on my adding local cache support to arm64-gate's make download? I know roughly what I'm doing to add it for git checkouts, still trying to figure out how I want to handle http gets of artifacts, etc

Eg, is this a thing I should add to mainline illumos-gate, should I just have it be default or have it require a flag? Or should I just put together an overly simple patch and discuss then?

'make download' should only need to actually do anything the first time, I think? unless somehow that changed when andyf and I made changes.

but I don't think I have objections? andy might be the best person to talk to, I'm not very online for the next little while for other reasons.

That's how it is still supposed to be - `make download` just the once

Sounds good. I'll keep thinking about it, if I have a strong opinion I'll make sure to have an argument in favor that isn't just about me.

Is there anything automatically building arm images right now? Or is that just manual.

[illumos-gate] 15822 Fully reset bhyve fwctl state if guest requests it -- John Baldwin <jhb⊙Fo>

[illumos-gate] 15809 bhyve TSC should exclude minimal host deltas -- Patrick Mooney <pmooney⊙pc>