Page MenuHomeFreeBSD

sctp: fix so_proto when peeling off a socket
ClosedPublic

Authored by tuexen on Mon, Feb 23, 9:03 AM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, Mar 6, 2:38 AM
Unknown Object (File)
Thu, Mar 5, 8:31 PM
Unknown Object (File)
Thu, Mar 5, 7:07 PM
Unknown Object (File)
Mon, Mar 2, 3:33 PM
Unknown Object (File)
Sun, Mar 1, 2:23 PM
Unknown Object (File)
Sun, Mar 1, 4:15 AM
Unknown Object (File)
Fri, Feb 27, 4:14 AM
Unknown Object (File)
Thu, Feb 26, 1:29 PM

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Skipped
Unit
Tests Skipped

Event Timeline

Any plans to add gencnt to SCTP sockets?

Olivier Van Acker did a GenAI lemming run with Cursor last week to auto-generate sctpsso(8) from tcpsso(8) as a template.

Whilst it generated an (at first) viable looking code artefact that compiled without error against FreeBSD 15.0-RELEASE, the AI model concerned had hallucinated the existence of two major things: gencnt existing for SCTP sockets, and a *.sockopt sysctl for SCTP to actually set the options.

This revision is now accepted and ready to land.Mon, Feb 23, 10:39 AM
In D55454#1268359, @bms wrote:

Any plans to add gencnt to SCTP sockets?

Olivier Van Acker did a GenAI lemming run with Cursor last week to auto-generate sctpsso(8) from tcpsso(8) as a template.

Whilst it generated an (at first) viable looking code artefact that compiled without error against FreeBSD 15.0-RELEASE, the AI model concerned had hallucinated the existence of two major things: gencnt existing for SCTP sockets, and a *.sockopt sysctl for SCTP to actually set the options.

How would you handle the assoc_id for one-to-many style sockets? Also provide that in sockstat? How did it handle the fact that most IPPROTO_SCTP-level socket options have a struct as the option value?

In D55454#1268359, @bms wrote:

Any plans to add gencnt to SCTP sockets?

Olivier Van Acker did a GenAI lemming run with Cursor last week to auto-generate sctpsso(8) from tcpsso(8) as a template.

Whilst it generated an (at first) viable looking code artefact that compiled without error against FreeBSD 15.0-RELEASE, the AI model concerned had hallucinated the existence of two major things: gencnt existing for SCTP sockets, and a *.sockopt sysctl for SCTP to actually set the options.

I dislike the term "hallucinated" since no, this is not a hallucination it is the AI LLM failing to read/interpret and build correct code. It's why AI is currently inferior. If I were
to write a bunch of code assuming that something existed because I did not bother to look at what I was writing to you would call that poor developer skills as
well as poor coding skills. With AI we say it "hallucinated", which is a crock, it just showed us its a poor developer with poor coding skills :-o

As Michael points out there are reasons SCTP exists the way it does...

How would you handle the assoc_id for one-to-many style sockets? Also provide that in sockstat? How did it handle the fact that most IPPROTO_SCTP-level socket options have a struct as the option value?

I guess some gross hack like a folded hash might be needed.

In D55454#1268412, @rrs wrote:

I dislike the term "hallucinated" since no, this is not a hallucination it is the AI LLM failing to read/interpret and build correct code. It's why AI is currently inferior. If I were
to write a bunch of code assuming that something existed because I did not bother to look at what I was writing to you would call that poor developer skills as
well as poor coding skills. With AI we say it "hallucinated", which is a crock, it just showed us its a poor developer with poor coding skills :-o

The correct term AI theorists seem to formally agree on is "confabulation". I learned today core@ have informally disallowed the use of so-called "vibe coding", but have not published formal policy for FreeBSD.org yet.

In my interactions with these systems, I find Emily Bender et al's nomenclature and practice of referring to them as "stochastic parrots" very helpful in describing and explaining the limitations of these systems: https://dl.acm.org/doi/10.1145/3442188.3445922

By far the biggest concern I have is the inability of Retrieval-Augmented Generation (RAG) enhanced Large Language Models (LLMs) to consistently cite or attribute the sources they use in their token-predicted text output. This surely clashes with the BSD copyright, GPLv2 copyleft, and CC-BY-SA attribution clauses, and invites gross intellectual property theft.

It is why I have moved my primary base of operations outside of FreeBSD.org to SourceHut, away from GitHub.

So, I currently use them only as pseudo-natural-language driven enhanced search engines and minimalist boilerplate code generation tools.

This revision was automatically updated to reflect the committed changes.