richlowe: it's a bit (ok, more than a bit) hacky, but what might work is you could make a copy of interface_check and remove this line: github.com/illumos/illumos-gate/blo…ols/scripts/interface_check.pl#L292

that would produce the interface output that includes the SUNWprivate and ILLUMOSprivate symbols

(or should at least)

which might then work with interface_cmp

or something like that

(I think interface_cmp will complain if a symbol disappears in the 'new' workspace)

at least for libraries

I have an assortment of scripts from last time where I was comparing gcc7 and 10 for things like size and content of CTF sections, function sizes and symbol changes. Nothing exciting but I can help with comparisons too.

I am hopeful that the delta from 10 to 14 will be a bit easier than 7 to 10 was.

andyf: Be on the lookout for things in 3rd-party software whose `configure` -generated C programs stop compiling in gcc14.

We've been building most things with gcc14 for a while and been through that pain. We have checks in the build system now that catch most of it

We have caught some of this, and output-diff-inspection of illumos-extra builds has shown even more that plow-on-with-bad-results. (Most egregious, endian-checks that say "We're big endian!")

Got hit in SCCS last week where it decided that all of our types were size 0, and by extension that must mean we have a 64-bit time_t.

Some of it may be due to older versions of things we have in -extra for reasons of sweater-unrevelling-avoidance.

SCCS... yeah I saw that on the mailing list.

It's useful to compare config.log between gcc13 and 14 to spot the most obvious things. I'm sure there are still lurking issues but we switched over to 14 a few months back.

One of the benefits of having stable releases, anything under r52 was built with <14

This isn't robust, but it's helped us a lot - omniosorg/omnios-extra 0930277

hi! i'm wondering if folks might have some quick thoughts on docs - github.com/illumos/dev-guide/blob/master/integrating and github.com/illumos/docs/blob/master/docs/contributing/index.md both talk about contributing and mostly overlap but not quite entirely. my read is that "illumos Developer's Guide" is a little more "here's the facts" and illumos.org/docs is more like "here's how we

suggest you read things and useful advice and conventions". does that sound like i'm reading it right? or is it just "they're updated when people get to it and so they've just drifted a bit"?

whoops long message :)

(in particular both documents talk about RTI but i had a hard time figuring out exactly what is wanted in practice and how to arrive at it. "yes, you should actually amend the commit. no, there is no tool for formatting it. yes, the formatting is not how git typically wants it. yes, push that commit to gerrit." etc)

for the commit message, it should be lines of '<ISSUE#> <SYNOPSIS>' (if there's multiple related changes being integrated in one commit, there may be multiple lines -- one for each issue), followed by one or more 'Reviewed by: User <email>'

the big difference is IIRC, a lot of places use 'Reviewed-by:' instead of "Reviewed by"

so you'll want to amend your commit after you have your reviewers

to reflect that

running 'git pbchk' should tell you if anything's wrong

the only other potential thing is the gerrit id

[illumos-gate] 16922 i86pc: support AMD C-states -- iximeow <illumos⊙in>

yeah, also we expect no blank line between the first line in a commit and subsequent description (e.g. it's not "summary + descriptions", the commit message is a free text field we're using differently)

i mostly want to know which place would be a better one to add this stuff, 'cause i found both along the way

yeah, no commentary in the commit -- i believe the reasoning is that it should be in redmine (issue tracker)

so just the summary

whoever approves your commit should take care of adding their 'Approved by:' line (since they'll be merging it for you)

I can't remember now (since I do it without thinking much about it)-- I git pbchk might complain about the gerrit id in the commit

it does yeah

just remove that line before submitting

I don't know for sure (so don't quote me on it :P), but I suspect there is an desire (but not the time to date) to eventually be able to do it all from gerrit -- i.e. advocates could give +1 which would allow it to merge w/ all the necessary tweaks to the commit message

(as it'd require some custom plugins to do all of that which means someone has to have the time to write them)

that's the sense i've gotten from talking with Andy and Patrick, but that there's work to do that

yeah

well. i'll do a PR to add some more explicit words against illumos.org/docs and figure out the book next

It'll definitely be good to get some updates there from your fresh perspective. Some of the things I suspect we don't have agreement on anyway, but this might shake some of those out.

I think jclulow will be able to give some direction on whether one of those guides is more current / intended to eventually replace the other.

The front page of illumos.org links to illumos.org/docs/contributing and I don't see the developers' guide mentioned any more.

Heh. except on the first part of that contributing guide.

:)

i believe rm has linked me to the developers' guide as well, but in the context of finding my way around the source tree

there's a lot of useful stuff there still for sure

andyf: I put a gcc-14 + arm64 together last night for testing, and the most surprising thing was autoconf checking things twice (at different levels, but together because parallel?) and getting _different answners_

I think that might even be prior to using the gcc 14, just building it

checking for sysctl... yes

checking for sysctl... no

on literally adjacent lines

heisenberg's sysctl

if I remember the excerpt I showed someone yesterday, I have all combinations of yes/yes, no/no, yes/no, no/yes

quantum computing is there, now:)

it would be interesting to see sample of its test program:)

are the two "checking for sysctl" tests trying the same code? the relevant bit of config.log might be enlightening.

I would bet they are different :)

and due to parallel run, the order of output is different.

iximeow: The developer's guide is meant to be like a book you can read, and I would consider illumos.org/docs to be where we communicate policy

I have had Big Thoughts about that recently

I think it's 'cos of he lack of daylight

I agree it's a bit unfortunate that there's overlap, and we should definitely make sure they line up

I think there's extent to which we would like to be more concise on the docs site sometimes?

jclulow: my Big Thoughts were: I've been documenting something lately, and I dropped it into the illumos source tree for now, so that it's totally clear whether it's getting updated as it should. That seems like it might just be a pretty good thing?

we build /man/ out of src/man/, there's no reason we couldn't build books out of /books/

ehhhhhh

Yes and?

and core know they're not drifting out of date if it has to get done in the same commit

one goes, "Where's the update to the documentation?" and not "Shit, I forgot about that" 6 months later

I feel like there's a lot of scope for docs work that doesn't need or require an RTI

I admit, I put a lot of faith in illumos' processes _actually_ shrinking to fit

I think part of having a different style of scrutiny over the docs stuff _is_ us shrinking to fit tbh

(by putting them elsewhere)

sure, I don't see why those too things are mutually dependent.

two, too

Mostly just squishy human social and psychological things probably

it also has the nominal advantage that you always have a copy of the docs that match your source tree

anyway, just a thing I got to thinking about because it goes dark too fucking early.

I think it's a good thing to think about for sure

I would also actually like us to _put more in the manual_

yeah, that would be amazing.

The manual isn't just a reference of command line flags

section 7 could always use more prose

and to be honest, mandoc is not painful.

Right, it's actually pretty alright.

I remain envious of, e.g., man.openbsd.org/afterboot

that page is actually one of the ones that really showed me that the man pages can be useful to read rather than flags reference

We have some good stuff in illumos.org/man/7

e.g., illumos.org/man/7/byteorder

now I'm going to have to learn whether pandoc can convert this thing I'm doing into mandoc

TIL PDP-endian

Yeah, DEC have a lot to answer for

There are also a handful of good kernel ones in illumos.org/man/9

richlowe: i've actually wondered about some sort of alternate format that could be converted to mandoc w/ good fidelity since regardless of the truth, it's common enough people see mandoc and be like 'that's too confusing/complicated/etc'

like mandoc could still live in the tree, but if someone wanted to write then convert

and a lot (all I've seen so far) of the markdown->mandoc/roff converters don't do a good job tbh

since the semantics are different

e.g. how do you annotate 'foo' is a function argument in markdown in a way that'll get translated to 'Fa'

?

(so is there something that could do that?)

like I cry a little everytime i have to read the smartos vmadm man page

(because the conversion from markdown is poor)

(at minimum it should be readable in an 80 column terminal without horizontal scrolling)

the problem is the only extant thing I can think of that'd work would be xml, which i'm not sure if it'd be any better/more attractive for people wanting to write man pages

jbk: I feel like mdoc is just not that complicated, and a good fit for documents in the UNIX ballpark, and if anything we should just write better documentation about how to get started with it etc

mdoc(7) is a great reference, but could probably use more introductory prose and guidance