- User Since
- Jul 4 2018, 7:23 PM (168 w, 4 h)
Mon, Sep 20
Sat, Sep 18
Fri, Sep 17
Handle L1 pages as those are uesd for the direct map
Thu, Sep 16
Wed, Sep 15
Mon, Sep 13
I don't think I understand the problem. SHA256_Transform is static, it should never be visible outside the object.
Sun, Sep 12
Fri, Sep 10
Just rename the file rather than adding a symlink at build time
Tue, Sep 7
Yeah these changes are pretty clearly fine :)
Mon, Aug 30
Thu, Aug 26
Yep that's another good observation... any more bugs you can think of with my original code? :)
Still an accept with the context added :)
Given pcib_grow_window also rounds requests it seems sensible to be consistent and do so here too. Not writing the updated window is indeed a silly oversight and explains why clear_pcib wasn't working for me on my board, stopping enumeration early. But best wait for John to check there isn't something I'm overlooking here.
Wed, Aug 25
Tue, Aug 24
Your description says you did one thing. You in fact did two things, each in a different file.
It's written this way because our C++ is deliberately very C-like. And it avoids all the std:: everywhere that's just a mess. Are there any useful changes you're making here other than changing it to match your personal views on style? The only somewhat useful thing I can see is changing some ints to bools, but even then it's all in tests so I really don't care all that much about a tiny increase in memory footprint.
- -O3 often bloats code
- Much of -O3's advantage, at least with GCC, is from autovectorisation, which is useless in the kernel as we turn off vectors due to the high context-switch overhead
- -O3 is underused and historically has come with more compiler bugs
Your description still completely ignores a large chunk of the unrelated changes you're making
This is now harder to read. If the input size is between INT_MIN (exclusive) and 0 (inclusive) you still overflow buf. If the input is exactly INT_MIN you still have signed integer overflow. This therefore adds nothing of value.
Yet again so much noise I'm not even bothering to give individual comments for
Your description is not what this does for userspace. It is what it does for the kernel but that is bad, now we have two copies of basically the same thing in one file.
Most of these changes have nothing to do with what your summary says
ANSIfying definitions has some value, but everything else seems like a complete waste of time to me...
Please elaborate on "Fix a bug in sifive_spi.c." when committing, and please mark for MFC (I have yet to do the big batch of MFCs for the other commits to stable/13 but will get round to it soon).