linux-kernel - Re: [GIT pull] timer updates for 4.19

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <alpine.DEB.2.21.1808262206010.1195@nanos.tec.linutronix.de>
Date:   Sun, 26 Aug 2018 22:10:56 +0200 (CEST)
From:   Thomas Gleixner <tglx@...utronix.de>
To:     Linus Torvalds <torvalds@...ux-foundation.org>
cc:     Arnd Bergmann <arnd@...db.de>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>, Christoph Hellwig <hch@....de>
Subject: Re: [GIT pull] timer updates for 4.19

On Sun, 26 Aug 2018, Linus Torvalds wrote:

> On Sun, Aug 26, 2018 at 2:39 AM Thomas Gleixner <tglx@...utronix.de> wrote:
> >
> > New defines for the compat time* types so they can be shared between 32bit
> > and 64bit builds. Not used yet, but merging them now allows the actual
> > conversions to be merged through different maintainer trees without
> > dependencies
> 
> So I pulled this, then looked at it a bit more, and went "that's stupid".
> 
> Why introduce a completely useless new name for something we already have?
> 
> Why can't the 32-bit code just use the "compat" names instead? Even
> for 32-bit systems, it's about compatibility with the old world order.
> 
> So what's the advantage of calling it "old" over just calling it "compat"?
> 
> I do not for a *second* believe that "compat" is somehow confusing to
> 32-bit architectures. They all have the new 64-bit time code already,
> it's not like there is any confusion what-so-ever about what is going
> on here.
> 
> The fact is, those 32-bit interfaces are FOR COMPATIBILITY with old
> binaries. What the hell is confusing about that? No, the real
> confusion would be to have yet another name for the same thing for no
> good reason.

We still have compat interfaces for 32bit on 64bit even with the new 2038
safe timespec/val variants because pointer size is different. And for the
old style timespec/val interfaces we need yet another 'compat' interface
for both 32bit native and 32bit on 64bit. That's why we need a different
name.

Thanks,

	tglx