is there any plan to upgrade gcc from 10 to 14 which used to compile OS?

the gcc 14 offer -march supports x86-64-v2, x86-64-v3, x86-64-v4

sommerfeld: I have been having some thoughts about IP tunnels and IPsec, which I've written up in: github.com/illumos/ipd/blob/master/ipd/0046/README.adoc

Would appreciate any thoughts or context before I put it out more widely!

jclulow: will look tomorrow.

Tah!

tozhu the specific version is not set. we still have some cleanups to do for 13/14 (about 20 components or patches) before we can start to think of using for secondary compiler.

[illumos-gate] 16727 pcfs_fstyp: multiple issues with FAT data processing -- Toomas Soome <tsoome⊙mc>

now mkfs? :D

I'm waiting for udfs

not because I use it, but because I know exactly how broken it is in userland

If someone has some time I could use a look at code.illumos.org/c/illumos-gate/+/3664.

→ CODE REVIEW 3664: 16754 libjedec support for LPDDR3-5, DDR3 16753 update libjedec for DDR5 SPD 1.2 16755 Overhaul and improve SPD tests, fallout 16756 Rename libjedec_test to better reflect vendor nature (NEW) | illumos.org/issues/16754

jclulow: read over your IPD 46 and it looks good. tagging policies with their owner makes sense and a similar tag should be used on routes. my bias would be for something fixed-size (id_t or uint64_t or the like) in the kernel to simplify the kernel innards

sommerfeld and jclulow ==> See my filed-issue about the existing SADB_X_KM_COOKIE and how it might help.

[illumos-gate] 16762 smbfs mdb module using wrong headers -- Gordon Ross <gwr⊙rc>

[illumos-gate] 16761 Let SMB client nsmb kmod use mapfiles -- Gordon Ross <gwr⊙rc>

jclulow: I also think that similar tagging should be done for routes - and I believe there are examples of that in other network stacks.

sommerfeld: Yeah I totally agree on the routes stuff

The two bits is a historical accident with which people have made do haha

There are other issues with route management as well, like the fact that an interface going down makes the routes that were attached to it ... invisible and unmanageable I think?

But like, they come back if it comes back up

which makes it pretty hard to do the right thing for BGP etc

danmcd: In this context the KM cookie is what the kernel gives you when it is requesting a dynamically created SA for some new flow?

gives you back, that is

so that you know which IKE session it is meant for?

(looks like FreeBSD imported netlink, which adds a "routing protocol" tag to each route)

jclulow: IIRC, yes

basically the kernel just gives you back whatever value you gave it when you created the SA

Right

I think the management tag would probably be separate from that

But I will have a look!

for ikev2 we expanded it (IIRC we just used some existing reserved space in the struct) to 64-bits

Yeah I found the ticket Dan mentioned

sommerfeld: I feel like we would need a new RTM_VERSION to add a tag there

And then some way to opt into it

Unfortunately the protocol argument in the socket() call is AF_INET (etc) so we'd have to do some kind of SOL_ROUTE thing probably

seems doable though?