In D13209#537057, @trasz wrote:

Ping? What's the status of this?

In D21638#531526, @asomers wrote:

Can we close this review now?

LGTM, but I have no time to test.
Note that this type of changes should be checked with an exxp-run

Update User Ports, attempting to bring balance with what can actually appear in a UNIX system.

I thought cem would want to do the commit.
I've been a bit sick, but I'll commit it this week if no one else does.

LGTM

The code is rather tricky, it would be convenient to checksum the object code on Little Endian to make sure nothing changes.

Approved BTW, the code obviously doesn't change anything for LE.

Hmm... if the tests pass I guess it is good, but does the comment need updating as well?
The else case in the old code was going backwards but this one doesn't.

It did compile but no joy sadly :(.
I left the complete log here:
https://people.freebsd.org/~pfg/docs/Xorg.0.log

Ugh.. I think this was discussed when __unreachable() was introduced (D2536 perhaps), and back then it was not considered a good idea.

IANA has indeed removed some services: I think people can de-register services they don't use/develop anymore. We should remove at least Kerberos IV and netatalk, both are not in the IANA. Also IANA lists first tcp, udp and lastly sctp so perhaps its better to jeep things consistent.

Sync with latest updates.

Update Take2:
It is important to consider the differences between System Ports and User
ports. This changes keeps the system ports closely in sync with IANA.

In D23621#518545, @cy wrote:

The fact that Kerberos IV is EOL doesn'[t mitigate the fact that the entries are still registered with IANA and that some KRB4 app may expect the entries to exist. Suggest we use https://www.iana.org/assignments/service-names-port-numbers/service-names-port-numbers.xhtml as a reference.

In D23621#518528, @mjg wrote:

If you want an example of what happens when a random parameter gets whacked out of proportion compared to Linux, here it is:

https://www.postgresql.org/message-id/CAEepm%3D3VF%3DPUp2f8gU8fgZB22yPE_KBS0%2Be1AHAtQ%3D09schTHg%40mail.gmail.com

Parameter set to 65536 because "why not" while it is 4096 on Linux resulted in a 256KB buffer in postgres when it should have been a fraction of that size. And so on. If there is no reason to deviate, don't.

Hello;

In D23621#518513, @mjg wrote:

Removing very stale entries or adding something may be fine, but the list as suggested is a non-starter. One has to expect there is plenty of custom userspace code parsing it which will choke on the new size.

Good, indeed r252956, which was the predecesor of this, was built on an UFS patch.
Well done, thanks!

Small fix .. and still very far from over.

Update.
I started modifying htree and lookup as well, but it's coming quickly
off-hand.

In D23259#510030, @fsu wrote:

I am not sure that dinode and superblock conversion will be enough, as I checked on linux side, the group descriptors should be converted too, possible same for bitmaps.
From https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout
"All fields in ext4 are written to disk in little-endian order"

Argh .. a look into the NetBSD code indicades the directory entries (atr least e2d_reclen and e2d_namlen) need special treatment as well. Not sure yet about names wichh are character strings.

In D23259#510030, @fsu wrote:

I am not sure that dinode and superblock conversion will be enough, as I checked on linux side, the group descriptors should be converted too, possible same for bitmaps.
From https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout
"All fields in ext4 are written to disk in little-endian order"

Yes, everything is in LE. The question is where does the transfer happen? The eraliest we do that, the better. Otherwise we should probably move the group descriptors to the dinode header, to have everything that must be translated in the same place.

LGTM. I forwarded the revision link to Tomohiro Kusumi from DragonFly as well.

Overcome by D22943 and SVN r356356.

Cool.
FWIW, it may make sense to MFC this code: it is under strong copyleft and getting linked with everything.

I am abandoning this line of changes: it doesnt bring any advantage.

Abandon: it was not exactly right.

Let me add Oliver as he was my student for GSoC 2015.

I am fine with this approach: while we do have an implementation of these functions (GSoC 2015), I don't think FORTIFY_SOURCE solves anything that we don't already do with the strong stack protector. Stubbing the functions out is a quick and practical solution.
We should still consider removing the stubs in a near future: I haven't looked at how linux does it but I think this stuff is not carried by glibc but in GCC libs instead.

In D22924#502329, @tuexen wrote:

Unpredictability is not important here, it is more the distribution. Any reason why the change has to happen?

Add some developers that are more likely to know the code better.

Add developers that are more likely to know better the code than me.

In D6442#502210, @delphij wrote:

In D6442#502200, @pfg wrote:

Hmm ...
When arc4random was introduced in OpenBSD the idea was to have one unique random algorithm to replace them all. This patch is old and reflects that idea. I am now thinking , that that is not the real objective for us.

Well, the idea is not purely unifying the generators, but to use the same CSPRNG in as much as possible places in kernel to make it harder to predicate the next output, by using these arc4random() calls as another form of randomness introduced to the entropy source (as such, to effectively use the feature the calls has to obtain small quantities of outputs from arc4random()).

That's said, I believe we still want to use arc4random() for, at least, the code paths that are not performance critical and do performance analysis and decide carefully if they should be used in the critical ones.

Drop revision: none of this is security critical and replacing good old random for the sake of removing it is not an objective.

Drop stuff that was moved to other differentials.

Hmm ...
When arc4random was introduced in OpenBSD the idea was to have one unique random algorithm to replace them all. This patch is old and reflects that idea. I am now thinking , that that is not the real objective for us.

In D6442#502158, @cem wrote:

I think it would be more straightforward to divide this into reviews by subject code area. Feel free to cc me in all of those if you do so. I’m happier to see more use of arc4random when it’s a good fit.