On Wed, Aug 24, 2022 at 4:36 PM Alejandro Colomar
wrote:
>
> I'm trying to be nice, and ask for review to make sure I'm not making
> some big mistake by accident, and I get disrespect? No thanks.
You've been told multiple times that the kernel doesn't use the
"standard" names, and *cannot* use t
On Wed, Aug 24, 2022 at 11:41 PM Florian Weimer wrote:
>
> The justifications brought forward are just regurgitating previous
> misinformation. If you do that, it's hard to take you seriously.
Pot, meet kettle.
> There is actually a good reason for using __u64: it's always based on
> long long,
On Thu, Aug 25, 2022 at 12:20 AM Alejandro Colomar
wrote:
>
> This patch is not about kernel, but about the section 2 and 3 manual
> pages, which are directed towards user-space readers most of the time.
They are about the types to the kernel interfaces. Those types that
the kernel defines and ex
On Thu, Aug 25, 2022 at 7:38 AM Joseph Myers wrote:
>
> I've not yet implemented it for glibc or for GCC format checking, but C23
> adds 'wN' format length modifiers so you will be able to e.g. use "%w64d"
> with printf to print an int64_t and won't need those PRI macros any more.
Yeah, that's go
On Sun, Jan 14, 2018 at 1:02 PM, David Woodhouse wrote:
> Review on the GCC patches has led to a request that the thunk symbols
> be changed from e.g. __x86_indirect_thunk_rax to
> __x86_indirect_thunk_ax without the 'r'.
Ok. I think that just makes it easier for us, since then the names are
inde
On Sun, Jan 14, 2018 at 2:39 PM, David Woodhouse wrote:
>
> I'm not convinced we want to do this, but I'll defer to Linus.
Well, I guess we have no choice, if gcc ends up using the stupid names.
And yes, apparently this just made our macros worse instead of
cleaning anything up. Oh well.
I do h
On Sun, Jan 14, 2018 at 3:09 PM, David Woodhouse wrote:
>
> I think we should stick with what we have now, with the names of the
> thunks actually being the *full* name of the register (rax, eax, etc.)
> that they use.
It that works for the gcc people, then yes, I agree. The mixed
"sometimes full
On Sun, Jan 14, 2018 at 3:23 PM, David Woodhouse wrote:
> I think we *shouldn't* do this. Uros said we could look at it and make
> a decision, and GCC would implement what we decide. Up to Linus.
Regardless of whether we end up having to do this, I'm not doing rc8
with it, and let's hope we can j
On Mon, 6 Jan 2025 at 16:13, Jeff Law wrote:
>
> But in the case of concurrent accesses, shouldn't these objects be
> declared as atomic?
No.
They aren't concurrent accesses to the same variable.
They are concurrent accesses to *different* memory locations, and the
compiler is not allowed to me
On Mon, 6 Jan 2025 at 16:59, Linus Torvalds
wrote:
>
> There is absolutely no gray area here. It was always buggy, and the
> alpha architecture was always completely and fundamentally
> mis-designed.
Note that I really do want to re-emphasize that while I think it's
kind of
10 matches
Mail list logo
