- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Feb 2 2020
Jan 31 2020
Jan 30 2020
Jan 29 2020
Jan 25 2020
Jan 24 2020
Jan 23 2020
Jan 22 2020
Jan 21 2020
Jan 19 2020
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.
Jan 16 2020
Jan 13 2020
LGTM. I forwarded the revision link to Tomohiro Kusumi from DragonFly as well.
Jan 11 2020
Jan 4 2020
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.
Dec 30 2019
I am abandoning this line of changes: it doesnt bring any advantage.
Abandon: it was not exactly right.
Dec 29 2019
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.
Dec 28 2019
Dec 27 2019
Dec 26 2019
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.
Dec 25 2019
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.
Drop one more case where the return type matters.
Drop some replacements wehre the different retrn value type is important.
Add cem@.
Update: some code has already been replaced.
Dec 24 2019
rebase the patches to match modern FreeBSD.
Dec 23 2019
cem@ has been adding some interesting support to fstyp so perhaps he may want to review or even take over.
Dec 21 2019
Dec 16 2019
Dec 15 2019
Dec 14 2019
Dec 11 2019
LGTM, I like sensible extensions.
Dec 10 2019
Dec 9 2019
FWIW,
It looks like we should update
contrib/libc++/include/__config around line 348.
Dec 3 2019
Dec 1 2019
Nov 28 2019
Nov 27 2019
Nov 20 2019
Nov 10 2019
Nov 1 2019
Oct 17 2019
Oct 7 2019
Oct 6 2019
Sep 29 2019
Sep 25 2019
Sep 17 2019
I am starting to concur that this call may be obsoleted.
Let me add the kqueue maintainer and the fuse maintainer (Alan added kqueue support to fuse) as they may shed some more light on this
Committed as r350970.